: 400570: 55 push %rbp 400571: 48 89 e5 mov %rsp,%rbp 400574: 48 83 ec 10 sub $0x10,%rsp 400578: b8 00 00 00 00 mov $0x0,%eax 40057d: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp) 400584: f2 0f 10 05 04 01 00 movsd 0x104(%rip),%xmm0 # 400690 <_IO_stdin_used+0x8> 40058b: 00 40058c: 89 45 f8 mov %eax,-0x8(%rbp) 40058f: b0 01 mov $0x1,%al 400591: e8 aa ff ff ff callq 400540 400596: 8b 45 f8 mov -0x8(%rbp),%eax 400599: 48 83 c4 10 add $0x10,%rsp 40059d: 5d pop %rbp 40059e: c3 retq 40059f: 90 nop which, of course, means foo is passed whatever happened to be in %edi at the time, rather than 42 as expected (e.g., it prints the number of command-line arguments on my system). If the prototype is moved after the function definition, the program works properly. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 12:48:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 12:48:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8315] New: Report error when applying a pointer-to-const-member-function to non-const object Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8315 Summary: Report error when applying a pointer-to-const-member-function to non-const object Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: benoit.belley at autodesk.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5573) --> (http://llvm.org/bugs/attachment.cgi?id=5573) Test case IClang fails to report an error when applying a pointer to a const member function to non-const reference or pointer as demonstrated by the following code example: ----------------------------------------------------------------------------------------------------- class ClassA {}; typedef void (ClassA::*PtrToMem)(); typedef void (ClassA::*PtrToConstMem)() const; void foo( ClassA a, const ClassA& a_const, ClassA* ap, const ClassA* ap_const, PtrToMem ptr_to_mem, PtrToConstMem ptr_to_const_mem ) { (a.*ptr_to_mem)(); (a.*ptr_to_const_mem)(); (a_const.*ptr_to_mem)(); // expected-error{{invalid conversion from 'const ClassA*' to 'ClassA*'}} (a_const.*ptr_to_const_mem)(); (ap->*ptr_to_mem)(); (ap->*ptr_to_const_mem)(); (ap_const->*ptr_to_mem)(); // expected-error{{invalid conversion from 'const ClassA*' to 'ClassA*'}} (ap_const->*ptr_to_const_mem)(); } ----------------------------------------------------------------------------------------------------- $ llvm/Debug+Asserts/bin/clang++ -c ptr_to_const_mem_bug.cpp $ ----------------------------------------------------------------------------------------------------- I am currently using the SVN revision 114947 of clang. Note that both the GNU g++ compiler and the Intel C++ compiler are properly reporting the errors: ----------------------------------------------------------------------------------------------------- $ g++ -c ptr_to_const_mem_bug.cpp ptr_to_const_mem_bug.cpp: In function 'void foo(ClassA, const ClassA&, ClassA*, const ClassA*, void (ClassA::*)(), void (ClassA::*)()const)': ptr_to_const_mem_bug.cpp:18: error: invalid conversion from 'const ClassA*' to 'ClassA*' ptr_to_const_mem_bug.cpp:24: error: invalid conversion from 'const ClassA*' to 'ClassA*? $ icpc -c ptr_to_const_mem_bug.cpp ptr_to_const_mem_bug.cpp(18): error: the object has cv-qualifiers that are not compatible with the member function object type is: const ClassA (a_const.*ptr_to_mem)(); // expected-error{{invalid conversion from 'const ClassA*' to 'ClassA*'}} ^ ptr_to_const_mem_bug.cpp(24): error: the object has cv-qualifiers that are not compatible with the member function object type is: const ClassA (ap_const->*ptr_to_mem)(); // expected-error{{invalid conversion from 'const ClassA*' to 'ClassA*'}} ^ compilation aborted for ptr_to_const_mem_bug.cpp (code 2) $ ----------------------------------------------------------------------------------------------------- Cheers, Benoit -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 17:00:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 17:00:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 8317] New: X86InstrInfo::convertToThreeAddress violates register class constraints Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8317 Summary: X86InstrInfo::convertToThreeAddress violates register class constraints Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: stoklund at 2pi.dk CC: llvmbugs at cs.uiuc.edu X86InstrInfo::convertToThreeAddress can change an SHL instruction into an LEA. This can break register class constraints because LEA cannot take ESP as an offset while SHL can. LEA requires a GR32_NOSP register while SHL only requires a GR32. This is an academic exercise since ESP is always reserved anyway, so it doesn't cause any invalid code to be generated. It does break the machine code verifier, though. X86InstrInfo::convertToThreeAddress should switch the regclass of SrcReg from GR32 to GR32_NOSP, and we may want to use GR32_NOSP as the default class for i32 values. The same applies to GR64_NOSP. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 17:39:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 17:39:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 8318] New: ARM EABI: inefficient code saving/restoring sp around function call Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8318 Summary: ARM EABI: inefficient code saving/restoring sp around function call Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: john at bass-software.com CC: llvmbugs at cs.uiuc.edu ToT & built both llvm-gcc and clang for arm-unknown-eabi target. This simple C program: --8<-- int foo(int a); int bar (int a) { return 5 + foo(a); } --8<-- Get compiled with clang as: $ clang -ccc-host-triple armv7-unknown-eabi -S -O3 -o test1.S test1.c && cat test1.S --8<-- .syntax unified .cpu cortex-a8 .eabi_attribute 10, 2 .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .file "test1.c" .text .globl bar .align 2 .type bar,%function bar: push {r11, lr} bl foo mov r11, sp <== ??? add r0, r0, #5 mov sp, r11 <== ??? ldmia sp!, {r11, pc} .Ltmp0: .size bar, .Ltmp0-bar --8<-- I.e. the save & restore of sp is very odd and unnecessary IMHO. When using llvm-gcc I don't get that output: $ arm-unknown-eabi-gcc -mcpu=cortex-a8 -O3 -S -O3 -o test1.S test1.c && cat test1.S --8<-- .syntax unified .cpu cortex-a8 .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .file "test1.c" .text .globl bar .align 2 .type bar,%function bar: push {r11, lr} bl foo add r0, r0, #5 ldmia sp!, {r11, pc} .Ltmp0: .size bar, .Ltmp0-bar .ident "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)" --8<-- -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 19:07:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 19:07:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 8317] X86InstrInfo::convertToThreeAddress violates register class constraints In-Reply-To: References: Message-ID: <20101007000752.F08432A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8317 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Jakob Stoklund Olesen 2010-10-06 19:07:52 CDT --- Fixed in r115879 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 20:55:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 20:55:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 8319] New: clang -O can't build ruby trunk Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8319 Summary: clang -O can't build ruby trunk Product: clang Version: trunk Platform: PC OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: naruse at airemix.jp CC: llvmbugs at cs.uiuc.edu clang -O can't build ruby trunk, but clang -O0 can build ruby trunk. So it seems some optimization breaks ruby. Ruby's code can be obtain from http://svn.ruby-lang.org/ and I tried with following: -- Ruby: r29419 on x86_64-freebsd8.1 clang version 2.9 (trunk 115816) Target: x86_64-unknown-freebsd8.1 Thread model: posix -- And its build process will crashes like following: -- snipped... /home/naruse/local/llvm/bin/clang -O -g -Wall -pedantic -Wno-long-long -Wno-gnu -Wno-unknown-pragmas -fPIC -I. -I.ext/include/x86_64-freebsd8.1 -I../../src/ruby-trunk/include -I../../src/ruby-trunk -include ruby/config.h -include ruby/missing.h -fvisibility=hidden -DRUBY_EXPORT -o dmyext.o -c ../../src/ruby-trunk/dmyext.c /home/naruse/local/llvm/bin/clang -O -g -Wall -pedantic -Wno-long-long -Wno-gnu -Wno-unknown-pragmas -fPIC -L. -rdynamic main.o dmydln.o dmyencoding.o dmyversion.o miniprelude.o array.o bignum.o class.o compar.o complex.o dir.o dln_find.o enum.o enumerator.o error.o eval.o load.o proc.o file.o gc.o hash.o inits.o io.o marshal.o math.o node.o numeric.o object.o pack.o parse.o process.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o regexec.o regparse.o regsyntax.o ruby.o safe.o signal.o sprintf.o st.o strftime.o string.o struct.o time.o transcode.o util.o variable.o compile.o debug.o iseq.o vm.o vm_dump.o thread.o cont.o ascii.o us_ascii.o unicode.o utf_8.o newline.o close.o dmyext.o -lthr -lrt -lcrypt -lm -o miniruby clang: warning: argument unused during compilation: '-g' clang: warning: argument unused during compilation: '-rdynamic' /usr/local/bin/ld: error in /usr/lib/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. :1: [BUG] Segmentation fault ruby 1.9.3dev (2010-10-07 trunk 29420) [x86_64-freebsd8.1] -- control frame ---------- c:0003 p:0002 s:0006 b:0006 l:000005 d:000005 TOP :1 c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH c:0001 p:0000 s:0002 b:0002 l:0008e8 d:0008e8 TOP --------------------------- -- Ruby level backtrace information ---------------------------------------- :1:in `' [NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html *** Signal 6 Stop in /home/naruse/obj/ruby-clang. -- The crashed binary, miniruby, is a ruby subset binary to make full ruby's files. In my understanding, it is happend on insns.def:868. -- 860 DEFINE_INSN 861 trace 862 (rb_num_t nf) 863 () 864 () 865 { 866 rb_event_flag_t flag = (rb_event_flag_t)nf; 867 868 EXEC_EVENT_HOOK(th, flag, GET_SELF(), 0, 0 /* TODO: id, klass */); 869 } -- And this GET_SELF() is:vm_insnhelper.h:146: #define GET_SELF() (USAGE_ANALYSIS_REGISTER_HELPER(5, 0, GET_CFP()->self)) GET_CFP() is: 112 #define GET_CFP() (USAGE_ANALYSIS_REGISTER_HELPER(2, 0, REG_CFP)) REG_CFP is: 81 #define REG_CFP (reg_cfp) This reg_cfp's value is vanished on clang -O, and crash. If I change Ruby's code as it uses reg_cfp before this, clang seems not optimize reg_cfp and ruby works well. --- insns.def (revision 29420) +++ insns.def (working copy) @@ -864,6 +864,7 @@ () { rb_event_flag_t flag = (rb_event_flag_t)nf; + if (!reg_cfp) sleep(1); EXEC_EVENT_HOOK(th, flag, GET_SELF(), 0, 0 /* TODO: id, klass */); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 21:24:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 21:24:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 8320] New: PECOFF: IMAGE_SYM_DTYPE_FUNCTION is incompatible to GNU binutils Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8320 Summary: PECOFF: IMAGE_SYM_DTYPE_FUNCTION is incompatible to GNU binutils Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: ASSIGNED Severity: normal Priority: P Component: Backend: X86 AssignedTo: bigcheesegs at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu GNU ld/PECOFF assumes .type 0x20 for function. LLVM emits .type 0x200, and GNU ld complains with warnings. (it might be harmless for execution) | c:/msysgit/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: Warning: type of symbol `_main' changed from 32 to 512 in utils/not/Release/not.o in include/llvm/Support/COFF.h, IMAGE_SYM_DTYPE_FUNCTION = 2, ///< A function that returns a base type. /// Type is formed as (base + (derived << SCT_COMPLEX_TYPE_SHIFT)) SCT_COMPLEX_TYPE_SHIFT = 8 it should be not 8 but 4 for compatibility to GNU binutils. FYI I have never met .type 0x200 even in object files emitted by MSVS8. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 22:04:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 22:04:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8321] New: MC-COFF: bogus reloc fixups to disp8/32 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8321 Summary: MC-COFF: bogus reloc fixups to disp8/32 Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: ASSIGNED Severity: normal Priority: P Component: Backend: X86 AssignedTo: bigcheesegs at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5576) --> (http://llvm.org/bugs/attachment.cgi?id=5576) pecoff object file w/o mc ; foo.ll define void @foo() { e: br label %i i: br label %i } define void @bar() { e: br label %i i: br label %i } define void @baz() { e: call void @baz() ret void } $ llc < foo.ll | as -o as-foo.o $ llc -filetype=obj foo.ll -o mc-foo.o * Disassembly of as-foo.o: 00000000 <_foo>: 0: eb fe jmp 0 <_foo> 00000010 <_bar>: 10: eb fe jmp 10 <_bar> 00000020 <_baz>: 20: 83 ec 04 sub $0x4,%esp 23: e8 f8 ff ff ff call 20 <_baz> 28: 83 c4 04 add $0x4,%esp 2b: c3 ret * Disassembly of mc-foo.o: 00000000 <_foo>: 0: e9 00 00 00 00 jmp 5 <_foo+0x5> 00000010 <_bar>: 10: e9 10 00 00 00 jmp 25 <_baz+0x5> 00000020 <_baz>: 20: 83 ec 04 sub $0x4,%esp 23: e8 00 00 00 00 call 28 <_baz+0x8> 28: 83 c4 04 add $0x4,%esp 2b: c3 ret mc-foo.o has also *unneeded* relocations. RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000001 DISP32 .text 00000011 DISP32 .text 00000024 DISP32 _baz+0xffffffe0 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 6 22:07:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 6 Oct 2010 22:07:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8322] New: Clang 2.8 Compile fails with: "address of overloaded function 'XXX' cannot be converted to type 'YYY' ", succeeds in GCC 4.4.1 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8322 Summary: Clang 2.8 Compile fails with: "address of overloaded function 'XXX' cannot be converted to type 'YYY' ", succeeds in GCC 4.4.1 Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: andy.somerville at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5578) --> (http://llvm.org/bugs/attachment.cgi?id=5578) attachment version of failure example to make downloading easier A somewhat complex code fails with: error: address of overloaded function 'XXX' cannot be converted to type 'YYY' Full details: c++ src/failure.cpp src/failure.cpp:19:65: error: address of overloaded function 'defaultMessageCreateFunction' cannot be converted to type 'function ()> const' const function(void)>& factory_fn = defaultMessageCreateFunction) {} ^ src/failure.cpp:30:13: note: in instantiation of default function argument expression for 'init' required here ops.template init(bind(fp, obj, _1)); ^ src/failure.cpp:43:13: note: in instantiation of function template specialization 'Foo::subscribe' requested here foo.subscribe( &FailureCase::callback, this); ^ src/failure.cpp:19:52: note: passing argument to parameter 'factory_fn' here const function(void)>& factory_fn = defaultMessageCreateFunction) {} ^ 1 error generated. src/failure.cpp (requires boost) //////////////////////////////////////////////////////////////// #include #include #include #include using namespace boost; template inline shared_ptr defaultMessageCreateFunction() { return make_shared(); } struct SubscribeOptions { template void init(const function&)>& _callback, const function(void)>& factory_fn = defaultMessageCreateFunction) {} }; class Foo { public: template void subscribe( void(T::*fp)(const shared_ptr&), T* obj) { SubscribeOptions ops; ops.template init(bind(fp, obj, _1)); } }; class FailureCase { class MessageType {}; typedef shared_ptr MessageTypeConstPtr; public: FailureCase() { foo.subscribe( &FailureCase::callback, this); } void callback(const MessageTypeConstPtr& msg) {} Foo foo; }; int main() { FailureCase failureCase; return 0; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 01:30:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 01:30:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8251] MC-COFF: GlobalAlias is not emitted In-Reply-To: References: Message-ID: <20101007063016.D11882A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8251 Michael Spencer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Michael Spencer 2010-10-07 01:30:16 CDT --- Fixed in r115909. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 05:11:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 05:11:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8323] New: ScheduleDAGSDNodes.cpp:301: ... "Node already inserted!" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8323 Summary: ScheduleDAGSDNodes.cpp:301: ... "Node already inserted!" Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM AssignedTo: unassignedbugs at nondot.org ReportedBy: Edmund.Grimley-Evans at arm.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5580) --> (http://llvm.org/bugs/attachment.cgi?id=5580) Patch to demonstrate bug I think this demonstrates a bug in the part of LLVM that handles Selection DAGs. Unfortunately I can't demonstrate it without patching LLVM. However, it's a small patch, so someone with the appropriate experience can probably say very quickly whether the patch itself is buggy. This started off as a much larger patch that did something useful. I've reduced it to a simple but silly patch that shows the same problem. Some notes on the patch: include/llvm/IntrinsicsARM.td: Add three intrinsics: magic_read, magic_test_eq and magic_test_lt, which each map i32 to i32. lib/Target/ARM/ARMISelLowering.h: Add three new DAG nodes: MAGIC_TEST (set the flags), MAGIC_MRS (move flags to register), MAGIC_MSR (move register to flags). lib/Target/ARM/ARMInstrThumb2.td: Add an instruction for MAGIC_TEST. We don't need instructions for the other two nodes as a peephole will remove them. lib/Target/ARM/ARMISelLowering.cpp: Two things: 1. In LowerINTRINSIC_WO_CHAIN map magic_read to MAGIC_TEST followed by MAGIC_MRS, and map magic_test_?? to MAGIC_MSR followed by a CMOV. 2. In PerformDAGCombine shortcircuit magic_MRS followed by magic_MSR. Now consider an example with magic_read followed by magic_test_eq: // Debug+Asserts/bin/llc t1.ll define arm_aapcscc i32 @f13(i32 %a) nounwind readnone { entry: %0 = tail call i32 @llvm.arm.magic.read(i32 %a) %1 = tail call i32 @llvm.arm.magic.test.eq(i32 %0) ret i32 %1 } This gets mapped to a sequence of MAGIC_TEST, MAGIC_MRS, MAGIC_MSR, CMOV. The peephole removes the MRS and MSR, and we're left with MAGIC_READ followed by CMOV, which turns into: magic_test r0 mov.w r0, #0 it eq moveq r0, #1 bx lr That's exactly what we expect. But now consider an example where the output of magic_read is used by both magic_test_eq and magic_test_lt: // Debug+Asserts/bin/llc t2.ll define arm_aapcscc i32 @f13(i32 %a) nounwind readnone { entry: %0 = tail call i32 @llvm.arm.magic.read(i32 %a) %1 = tail call i32 @llvm.arm.magic.test.eq(i32 %0) %2 = tail call i32 @llvm.arm.magic.test.lt(i32 %0) %add = add nsw i32 %2, %1 ret i32 %add } Now we get the assertion failure: llc: ScheduleDAGSDNodes.cpp:301: void llvm::ScheduleDAGSDNodes::BuildSchedUnits(): Assertion `N->getNodeId() == -1 && "Node already inserted!"' failed. Can anyone confirm that this represents a bug? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 07:13:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 07:13:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 8324] New: llvm-config --libdir results in wrong output on most 64-bit Linux systems Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8324 Summary: llvm-config --libdir results in wrong output on most 64-bit Linux systems Product: tools Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llvm-config AssignedTo: unassignedbugs at nondot.org ReportedBy: bero at arklinux.org CC: llvmbugs at cs.uiuc.edu Most 64-bit Linux systems place their (native 64bit) libraries in /usr/lib64, keeping /usr/lib for 32bit libraries for compatibility with legacy applications. llvm libraries are no exception - they're generally installed in /usr/lib64 llvm-config.in.in, line 69, however, hardcodes the assumption that things are installed to $ABS_RUN_DIR/lib, causing it to output wrong values if it should be $ABS_RUN_DIR/lib64 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 07:21:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 07:21:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8325] New: Error on throwing pointer to pointee with non public destructor Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8325 Summary: Error on throwing pointer to pointee with non public destructor Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: beckmann.maik at googlemail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com When throwing a pointer, clang wants the dtor of the pointee to be public. class Error { virtual ~Error() {} public: // uses decref() and incref() for reference counting }; void throwing() { throw new Error; } int main(int argc, char *argv[]) { try { throwing(); } catch (Error* e) { } return 0; } // clang++ -o test test.cpp // test.cpp:8:9: error: exception object of type 'Error' has private destructor // throw new Error; // ^ // test.cpp:2:11: note: declared private here // virtual ~Error() {} // ^ // 1 error generated. % clang++ --version clang version 2.8 (branches/release_28) Target: x86_64-unknown-linux-gnu Thread model: posix -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 08:34:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 08:34:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8326] New: const union member in template class gives invalid error Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8326 Summary: const union member in template class gives invalid error Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ext-llvm.org at sidvind.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5583) --> (http://llvm.org/bugs/attachment.cgi?id=5583) test case const_union_member.cpp:5:3: error: constructor for 'Foo' must explicitly initialize the const member '' Foo() ^ const_union_member.cpp:21:12: note: in instantiation of member function 'Foo::Foo' requested here Foo baz; ^ const_union_member.cpp:11:9: note: '' declared here const union { Both gcc and msvc accepts the code, and no error is generated if const or template is dropped. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 08:39:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 08:39:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 7981] -Wformat gives erronous warning for %lc In-Reply-To: References: Message-ID: <20101007133901.D11732A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7981 Dan McGee changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |dan at archlinux.org Resolution|FIXED | --- Comment #4 from Dan McGee 2010-10-07 08:39:01 CDT --- Not fixed in clang 2.8, I hope I'm not in error reopening this: Test case: $ cat test.c #include #include int main(int argc, char *argv[]) { wchar_t foo; foo = L't'; printf("%lc", foo); printf("%lc", (wint_t)foo); } $ gcc test.c && ./a.out tt $ clang test.c && ./a.out test.c:9:12: warning: conversion specifies type 'int' but the argument has type 'wint_t' (aka 'unsigned int') [-Wformat] printf("%lc", (wint_t)foo); ~~^ ~~~~~~~~~~~ %u 1 warning generated. tt $ clang --version clang version 2.8 (branches/release_28) Target: x86_64-unknown-linux-gnu Thread model: posix This compiled without warnings in clang 2.7. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 09:24:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 09:24:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8327] New: LLVM miscompiles va_arg() on 64-bit PowerPC, truncating address to 32 bits Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8327 Summary: LLVM miscompiles va_arg() on 64-bit PowerPC, truncating address to 32 bits Product: new-bugs Version: trunk Platform: Macintosh OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nwhitehorn at freebsd.org CC: llvmbugs at cs.uiuc.edu On 64-bit PowerPC, LLVM trunk (r115623) miscompiles va_arg: %3 = va_arg i8** %foo, i8* ; [#uses=2] to this code: lis 3, 8191 ori 3, 3, 65535 # r3 now contains 0x1ffffff ld 4, 296(31) # address of foo in r4 addi 4, 4, 7 # some kind of rounding with the next masking? sldi 3, 3, 3 # r3 is now mask 0xfffffff8 and 3, 4, 3 # and with r4, truncating foo to 8-byte alignment # (and killing top 32 bits) addi 4, 3, 8 # increment foo (r4) to next VA arg std 4, 296(31) # store back to foo Because the generated mask is only 32 bits wide, anding it with the VA arg pointer has the effect of zeroing the high 32-bits, causing a seg fault. I'm not entirely sure why it goes to the trouble of all the rounding code here, but the mask should at least be 64 bits on this platform. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 09:33:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 09:33:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8328] New: Unable to call method of incomplete class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8328 Summary: Unable to call method of incomplete class Product: clang Version: trunk Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Testcase below fails with the message: error: cannot dereference pointer into incomplete class type 'D' This is wrong. There is no problem in calling such method at all since the class itself isn't used in the process. Such pattern may be used by various projects and should compile fine. It works in gcc. rev.115483 --- testcase --- class D; typedef void (D::*Fn)(); void f(D *d, Fn fn) { (d->*fn)(); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 10:19:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 10:19:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 8329] New: getDefaultArgRange() returns empty SourceRange Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8329 Summary: getDefaultArgRange() returns empty SourceRange Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bugzilla-clang at sogetthis.com CC: llvmbugs at cs.uiuc.edu When getDefaultArgRange() is called for any ParmVarDecl the resulting SourceRange's beginning and end are equal. Both refer to the start of the actual default argument. To get the real source range one has to adapt the end of the range via Lexer::MeasureTokenLength(). Nevertheless the documentation for getDefaultArgRange() claims it will "Retrieve the source range that covers the entire default argument." which is IMHO outright wrong. So either the method needs to return the correct source range or the comment and probably the method name need to be changed according to what it actually does, e.g. getDefaultSourceLocation(). example ------- void bluh(const ParmVarDecl& p, const SourceManager& sm) { if(p.hasDefaultArg()) { clang::SourceRange range = p.getDefaultArgRange(); range.getBegin().print(llvm::errs(), sm); llvm::errs() << " - "; range.getEnd().print(llvm::errs(), sm); llvm::errs() << "'\n"; } } when wrapped and executed for this code $ cat test.cpp void blah(int a = 1); prints test.cpp:1:22 - test.cpp:1:22 expected output test.cpp:1:22 - test.cpp:1:23 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 13:32:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 13:32:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 8330] New: tblgen isn't sufficiently meta Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8330 Summary: tblgen isn't sufficiently meta Product: tools Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: TableGen AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu This crashes tblgen: ------ class Or4 Val> { bits<8> V = {Val{7}, Val{6}, Val{5}, Val{4}, Val{3}, 1, Val{1}, Val{0} }; } class Whatev x>; multiclass X BaseOpc> { def bar : Whatev.V >; } defm a : X<4>; ------ The problem is that tblgen needs to complete the instantiation of the anonymous def "Or4", and when it does this there are still symbolic references to BaseOpC. TableGen doesn't have a way to represent this and helpfully responds by crashing. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 13:36:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 13:36:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 8331] New: The return value of realloc should be checked before the next write Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8331 Summary: The return value of realloc should be checked before the next write Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: tom.care at uqconnect.edu.au ReportedBy: tom.care at uqconnect.edu.au CC: kremenek at apple.com, llvmbugs at cs.uiuc.edu After a realloc, the return value should be null checked, especially if there is an offset write to the pointer afterwards. A checker for this should be relatively simple. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 14:29:59 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 14:29:59 -0500 (CDT) Subject: [LLVMbugs] [Bug 8332] New: llvm-gcc inline asm regression wrt 2.7 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8332 Summary: llvm-gcc inline asm regression wrt 2.7 Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Both gcc and llvm-gcc from LLVM 2.7 accept this, however latest llvm-gcc says: $ llvm-gcc -S asm-4.c error: invalid operand in inline asm: 'test2 X${0:a}Y${0:a}Z' This is on x86-64 linux. Testcase: int main() { int z; asm volatile ("test2 X%a0Y%a[arg]Z" : : [arg] "p" (&z)); } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 17:26:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 17:26:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8333] New: 0 size allocations Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8333 Summary: 0 size allocations Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer AssignedTo: tom.care at uqconnect.edu.au ReportedBy: tom.care at uqconnect.edu.au CC: kremenek at apple.com, llvmbugs at cs.uiuc.edu Allocations with a size of 0 are easy bugs to find. See http://hackitoergosum.org/wp-content/uploads/2010/04/HES10-jvanegue_zero-allocations.pdf for examples. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 18:58:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 18:58:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 8321] MC-COFF: bogus reloc fixups to disp8/32 In-Reply-To: References: Message-ID: <20101007235812.ADAA32A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8321 Michael Spencer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Michael Spencer 2010-10-07 18:58:12 CDT --- Fixed in r116013. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 19:56:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 19:56:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 8334] New: Wrong template parameter is used for default copy constructor of template class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8334 Summary: Wrong template parameter is used for default copy constructor of template class Product: clang Version: trunk Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: yuri at tsoft.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com In the attached example stl::list is redefined in different namespace with different allocator. Auto-generated copy constructor has wrong allocator template parameter and fails in STL code: In file included from /usr/include/c++/4.2/list:69: /usr/include/c++/4.2/bits/stl_list.h:1179:30: error: invalid operands to binary expression ('_Node_alloc_type' (aka 'my_alloc >') and '_Node_alloc_type') if (_M_get_Node_allocator() != __x._M_get_Node_allocator()) ~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 7 22:17:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 7 Oct 2010 22:17:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 8320] PECOFF: IMAGE_SYM_DTYPE_FUNCTION is incompatible to GNU binutils In-Reply-To: References: Message-ID: <20101008031743.554A72A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8320 Michael Spencer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Michael Spencer 2010-10-07 22:17:42 CDT --- The correct value is indeed x20. Microsoft's documentation is contradictory, but previous COFF standards all support a one byte type instead of two bytes. Fixed in r116037. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 06:22:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 06:22:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 8335] New: MC-COFF: Wrong section header with module asm ".text" Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8335 Summary: MC-COFF: Wrong section header with module asm ".text" Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: ASSIGNED Severity: normal Priority: P Component: Backend: X86 AssignedTo: bigcheesegs at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu foo.ll: module asm ".text" module asm "_foo:" module asm "ret" $ llc -filetype=obj foo.ll $ objdump -x foo.o BFD: asm.o (.text): Section flag STYP_DSECT (0x1) ignored BFD: asm.o (.text): Section flag STYP_DSECT (0x1) ignored C:\msysgit\mingw\bin\objdump.exe: asm.o: File format not recognized Sections = [ 1 = { Name = .text VirtualSize = 0 VirtualAddress = 0 SizeOfRawData = 1 PointerToRawData = 0x3C PointerToRelocations = 0x0 PointerToLineNumbers = 0x0 NumberOfRelocations = 0 NumberOfLineNumbers = 0 Charateristics = 0x100001 IMAGE_SCN_ALIGN_1BYTES SectionData = C3 |.| Relocations = None } ] Module asm is used in X86JITInfo.cpp. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 09:26:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 09:26:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 8336] New: clang hangs while optimizing a snippet of C code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8336 Summary: clang hangs while optimizing a snippet of C code Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: pipping at exherbo.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5590) --> (http://llvm.org/bugs/attachment.cgi?id=5590) minimal working example I've tried to compile wpa_supplicant with clang 2.8. I believe this worked with clang 2.7, it certainly does with gcc 4.4.4. While compiling src/crypto/sha256.c, clang appears to hang (or take insanely long with 100% cpu load) This does not happen with gcc 4.4.4, or when optimization is turned of (-O1 hangs, -O0 does not). I believe it also didn't happen with clang 2.7 although I'm not sure. I've attached a minimal working example. I'm on amd64 linux 2.6.35.6. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 09:27:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 09:27:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8337] New: Dereference of null pointer Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8337 Summary: Dereference of null pointer Product: clang Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer AssignedTo: kremenek at apple.com ReportedBy: zdenek.kabelac at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5591) --> (http://llvm.org/bugs/attachment.cgi?id=5591) source file of problematic match Bug reported by the clang static analyzer. Description: Dereference of null pointer File: lvm2.git/daemons/clvmd/clvmd.c Line: 500 this is false positive - as could be seen from source - few lines above - there is check of ptr clops - and child_init_signal(status) with non-zero status parameter runs exit(status) - thus could never reach given condition -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 10:18:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 10:18:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 3406] [loop-index-split] llvm::SplitCriticalEdge can't update DomFrontier info without DomTree info In-Reply-To: References: Message-ID: <20101008151833.239902A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3406 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dpatel at apple.com Resolution| |INVALID --- Comment #3 from Devang Patel 2010-10-08 10:18:32 CDT --- LoopIndexSplit pass has been removed from svn. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 10:19:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 10:19:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 7933] Loop Index Split pass changes semantics of source program In-Reply-To: References: Message-ID: <20101008151910.86CCC2A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7933 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED CC| |dpatel at apple.com Resolution| |INVALID --- Comment #4 from Devang Patel 2010-10-08 10:19:09 CDT --- LoopIndexSplit pass has been removed from svn. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 10:20:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 10:20:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 3089] Apparent miscompilation with -loop-index-split -loop-rotate -loop-reduce In-Reply-To: References: Message-ID: <20101008152003.3BEA62A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=3089 Devang Patel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #6 from Devang Patel 2010-10-08 10:20:02 CDT --- LoopIndexSplit pass has been removed from svn. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 10:55:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 10:55:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8338] New: MC-COFF: section.bss always has .size as 0 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8338 Summary: MC-COFF: section.bss always has .size as 0 Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: ASSIGNED Severity: normal Priority: P Component: Backend: X86 AssignedTo: bigcheesegs at gmail.com ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu It seems mccoff emits .bss with size 0 in section headers. In getSectionFileSize(), *virtual* section is treated as size zero. A trivial patch. Now I can build FileCheck.exe and tblgen.exe with clang++ -integrated-as. opt.exe, clang.exe &c still crash for me. --- a/lib/MC/WinCOFFObjectWriter.cpp +++ b/lib/MC/WinCOFFObjectWriter.cpp @@ -799,7 +799,7 @@ void WinCOFFObjectWriter::WriteObject(MCAssembler &Asm, if (Sec->Number == -1) continue; - Sec->Header.SizeOfRawData = Layout.getSectionFileSize(i); + Sec->Header.SizeOfRawData = Layout.getSectionAddressSize(i); if (IsPhysicalSection(Sec)) { Sec->Header.PointerToRawData = offset; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 11:33:37 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 11:33:37 -0500 (CDT) Subject: [LLVMbugs] [Bug 8339] New: Clang driver has trouble parsing Gentoo-built linker version string Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8339 Summary: Clang driver has trouble parsing Gentoo-built linker version string Product: clang Version: trunk Platform: PC OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: Driver AssignedTo: unassignedclangbugs at nondot.org ReportedBy: cdavis at mymail.mines.edu CC: llvmbugs at cs.uiuc.edu Daniel, have I got a pathological driver test case for you. I have a Gentoo prefix installed on one of my systems. As you may or may not know, this is a setup where a Gentoo directory tree is installed in some other directory on the system. This being Gentoo, they insist on building everything, including the compiler and linker, from source. Since the linker gets built from source (with patches), the version string is modified like so: chip at chips-computer-3 ~ $ ld -v @(#)PROGRAM:ld PROJECT:ld64-97.14 (Gentoo binutils-apple-3.2.3-r1) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note the added part in parentheses (with Clang-style emphasis added by me). This isn't present in normal Apple builds of the linker. Unfortunately, the -mlinker-version argument barfs on this when the driver passes it to the frontend. This causes the tests Driver/hello.c and Driver/nostdincxx.cpp to fail horribly. I think we need to chop off the part in the parentheses when we build the driver. What do you think? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 12:10:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 12:10:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 8340] New: Is vector size zero allowed? Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8340 Summary: Is vector size zero allowed? Product: Documentation Version: trunk Platform: Other OS/Version: All Status: NEW Keywords: documentation Severity: normal Priority: P Component: General docs AssignedTo: unassignedbugs at nondot.org ReportedBy: llvm at henning-thielemann.de CC: llvmbugs at cs.uiuc.edu The documentation at http://www.llvm.org/docs/LangRef.html#t_vector says, that the vector size is an integer. This suggests that the size can also be negative, but I think this is not intended. Nonetheless the question remains, whether vectors of size 0 are allowed or not. Vectors exist merely for optimization purposes, which is different from arrays. I use vectors for chunking arrays for optimization reasons. In this context vectors of size zero make no sense. In the Haskell interface to LLVM I like to have precise type constraints, that is, if vectors of size zero are forbidden, then the type checker shall reject vectors of size zero. If size zero is allowed, then the type checker shall allow size zero as well. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 15:50:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 15:50:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 6955] [designated inits] crash when compiling arch/x86/kernel/cpu/common.c from linux kernel In-Reply-To: References: Message-ID: <20101008205029.B01922A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6955 Alp Toker changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #6 from Alp Toker 2010-10-08 15:50:28 CDT --- Landed r116098. Thanks dgregor! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 15:57:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 15:57:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 6537] codegen hack due to designated init AST bug In-Reply-To: References: Message-ID: <20101008205736.97A2F2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6537 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #9 from Douglas Gregor 2010-10-08 15:57:34 CDT --- Fixed in r116098 by Alp Toker, hack removed in r116101. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 16:04:25 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 16:04:25 -0500 (CDT) Subject: [LLVMbugs] [Bug 8341] New: lit.site.cfg doesn't specify character encoding. python complains on unicode paths. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8341 Summary: lit.site.cfg doesn't specify character encoding. python complains on unicode paths. Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu SyntaxError: Non-ASCI character '\xc3' in file /llvm-2.8/tools/clang/test/lit.site.cfg on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details. Where was some unicode path. The fix in this case was to add: # -*- coding: utf-8 -*- But I'm not sure this is correct in the general case. People use other encodings than utf-8. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 16:27:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 16:27:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 8329] getDefaultArgRange() returns incomplete SourceRange In-Reply-To: References: Message-ID: <20101008212748.20A622A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8329 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Douglas Gregor 2010-10-08 16:27:47 CDT --- Clang is behaving correctly. See http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-August/010595.html for an explanation of how source ranges work. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 17:55:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 17:55:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8342] New: Direct-initialization of class object by its own class Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8342 Summary: Direct-initialization of class object by its own class Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: schaub-johannes at web.de CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Clang does not like the following code struct A { A(int) { } explicit A(A const&) { } }; int main() { A a = 1; } The copy of the created A temporary to "a" is direct-initialization and so needs to consider the explicit copy constructor. But clang says main1.cpp:7:5: error: no viable constructor copying variable of type 'A' -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 18:32:03 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 18:32:03 -0500 (CDT) Subject: [LLVMbugs] [Bug 8343] New: [MC] No support for COFF assembly. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8343 Summary: [MC] No support for COFF assembly. Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu Blocks: 8335 There is currently no support in MC for parsing COFF assembly. Add it. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 20:06:00 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 20:06:00 -0500 (CDT) Subject: [LLVMbugs] [Bug 8344] New: Scoped over.built OO_Conditional enum fix Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8344 Summary: Scoped over.built OO_Conditional enum fix Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alp at nuanti.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com r116122 added C++0x scoped enum support. This is similar to our implementation (which we never got round to upstreaming, need to find a way to push these patches and get them reviewed faster), but we have an additional fix covering C++ [over.built]p25 which I've updated to ToT and attached to this bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 8 20:40:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 8 Oct 2010 20:40:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8345] New: Failure to compile templated atomic Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8345 Summary: Failure to compile templated atomic Product: clang Version: 2.8 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: dustin at spy.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com I've got a class that wraps __sync_* functions and provides atomics of various types. This fails to compile with clang if I use it with more than one type. templated-atomic.cc:10:37: error: cannot initialize a parameter of type 'long long volatile *' with an rvalue of type 'int volatile *' return __sync_add_and_fetch(&value, 1); ^~~~~~ templated-atomic.cc:21:5: note: in instantiation of member function 'Atomic::operator++' requested here ++ai; ^ 1 error generated. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Oct 9 06:01:39 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Oct 2010 06:01:39 -0500 (CDT) Subject: [LLVMbugs] [Bug 8343] [MC] No support for COFF assembly. In-Reply-To: References: Message-ID: <20101009110139.0FB7B2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8343 Michael Spencer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Michael Spencer 2010-10-09 06:01:38 CDT --- Fixed in r116150. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Oct 9 10:44:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Oct 2010 10:44:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8335] MC-COFF: Wrong section header with module asm ".text" In-Reply-To: References: Message-ID: <20101009154446.304412A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8335 Michael Spencer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #2 from Michael Spencer 2010-10-09 10:44:45 CDT --- Fixed in r116151. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Oct 9 11:05:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Oct 2010 11:05:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 8338] MC-COFF: section.bss always has .size as 0 In-Reply-To: References: Message-ID: <20101009160505.76FAA2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8338 Michael Spencer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from Michael Spencer 2010-10-09 11:05:05 CDT --- Fixed in r116115. Got any more bugs? :P -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sat Oct 9 15:18:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sat, 9 Oct 2010 15:18:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 8346] New: clang under windows/mingw inserts visible standard library functions into object files Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8346 Summary: clang under windows/mingw inserts visible standard library functions into object files Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ambrop7 at gmail.com CC: llvmbugs at cs.uiuc.edu > clang -O2 -c x.c > clang -O2 -c y.c > clang -o a.exe x.o y.o (or gcc) y.o:fake:(.text+0x0): multiple definition of `strncasecmp' x.o:fake:(.text+0x0): first defined here y.o:fake:(.text+0x10): multiple definition of `strcasecmp' x.o:fake:(.text+0x10): first defined here collect2: ld returned 1 exit status clang: error: linker (via gcc) command failed with exit code 1 (use -v to see in vocation) How I set up clang: Downloaded a 32-bit compiler from http://mingw-w64.sourceforge.net/ which I unpacked to c:\\mingw. Installed clang with: > set PATH=%PATH%;c:\mingw\bin > cmake ..\llvm -G "MinGW Makefiles" -DC_INCLUDE_DIRS=C:\\mingw\\i686-w64-mingw32\\include > mingw32-make install Did this before running the above clang commands: > set PATH=%PATH%;c:\mingw\bin;C:\Program Files\LLVM\bin Also made the following change to llvm to get it to compile: --- lib/System/Win32/DynamicLibrary.inc (revision 116150) +++ lib/System/Win32/DynamicLibrary.inc (working copy) @@ -49,13 +49,11 @@ extern "C" { // Use old callback if: -// - Not using Visual Studio // - Visual Studio 2005 or earlier but only if we are not using the Windows SDK // or Windows SDK version is older than 6.0 -// Use new callback if: -// - Newer Visual Studio (comes with newer SDK). -// - Visual Studio 2005 with Windows SDK 6.0+ -#if !defined(_MSC_VER) || _MSC_VER < 1500 && (!defined(VER_PRODUCTBUILD) || VER_PRODUCTBUILD < 6000) +// - W32Api older than 3.12 +#if (defined(_MSC_VER) && _MSC_VER < 1500 && (!defined(VER_PRODUCTBUILD) || VER_PRODUCTBUILD < 6000)) || \ + (defined(__W32API_VERSION) && (__W32API_MAJOR_VERSION < 3 || (__W32API_MAJOR_VERSION == 3 && __W32API_MINOR_VERSION < 12))) static BOOL CALLBACK ELM_Callback(PSTR ModuleName, ModuleBaseType ModuleBase, ULONG ModuleSize, -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Oct 10 02:12:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Oct 2010 02:12:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 8347] New: ARM VA_ARG Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8347 Summary: ARM VA_ARG Product: tools Version: trunk Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: pdox at alum.mit.edu CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5599) --> (http://llvm.org/bugs/attachment.cgi?id=5599) open_with_hook is a wrapper for open() which calls va_arg It looks like Post-RA instruction reordering is causing the instruct -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Oct 10 02:31:17 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Oct 2010 02:31:17 -0500 (CDT) Subject: [LLVMbugs] [Bug 8348] New: [MC-COFF] COFF backend can't handle weak symbols Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8348 Summary: [MC-COFF] COFF backend can't handle weak symbols Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: bigcheesegs at gmail.com ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu .def _main; .scl 2; .type 32; .endef .text .globl _main .align 16, 0x90 _main: # @main # BB#0: # %entry subl $4, %esp movl $_test_weak, %eax testl %eax, %eax je LBB0_2 # BB#1: # %if.then calll _test_weak movl $1, %eax addl $4, %esp ret LBB0_2: # %return xorl %eax, %eax addl $4, %esp ret .weak _test_weak llvm-mc -filetype=obj chrashes. as produces: { MachineType = IMAGE_FILE_MACHINE_I386 (0x14C) NumberOfSections = 3 TimeDateStamp = 0 PointerToSymbolTable = 0xC0 NumberOfSymbols = 13 SizeOfOptionalHeader = 0 Characteristics = 0x104 IMAGE_FILE_LINE_NUMS_STRIPPED IMAGE_FILE_32BIT_MACHINE Sections = [ 1 = { Name = .text VirtualSize = 0 VirtualAddress = 0 SizeOfRawData = 32 PointerToRawData = 0x8C PointerToRelocations = 0xAC PointerToLineNumbers = 0x0 NumberOfRelocations = 2 NumberOfLineNumbers = 0 Charateristics = 0x60500020 IMAGE_SCN_CNT_CODE IMAGE_SCN_ALIGN_16BYTES IMAGE_SCN_MEM_EXECUTE IMAGE_SCN_MEM_READ SectionData = 83 EC 04 B8 00 00 00 00 - 85 C0 74 0E E8 00 00 00 |..........t.....| 00 B8 01 00 00 00 83 C4 - 04 C3 31 C0 83 C4 04 C3 |..........1.....| Relocations = [ 0 = { VirtualAddress = 0x4 SymbolTableIndex = 11 Type = IMAGE_REL_I386_DIR32 (6) SymbolName = _test_weak } 1 = { VirtualAddress = 0xD SymbolTableIndex = 11 Type = IMAGE_REL_I386_REL32 (20) SymbolName = _test_weak } ] } 2 = { Name = .data VirtualSize = 0 VirtualAddress = 0 SizeOfRawData = 0 PointerToRawData = 0x0 PointerToRelocations = 0x0 PointerToLineNumbers = 0x0 NumberOfRelocations = 0 NumberOfLineNumbers = 0 Charateristics = 0xC0300040 IMAGE_SCN_CNT_INITIALIZED_DATA IMAGE_SCN_ALIGN_4BYTES IMAGE_SCN_MEM_READ IMAGE_SCN_MEM_WRITE SectionData = None Relocations = None } 3 = { Name = .bss VirtualSize = 0 VirtualAddress = 0 SizeOfRawData = 0 PointerToRawData = 0x0 PointerToRelocations = 0x0 PointerToLineNumbers = 0x0 NumberOfRelocations = 0 NumberOfLineNumbers = 0 Charateristics = 0xC0300080 IMAGE_SCN_CNT_UNINITIALIZED_DATA IMAGE_SCN_ALIGN_4BYTES IMAGE_SCN_MEM_READ IMAGE_SCN_MEM_WRITE SectionData = None Relocations = None } ] Symbols = [ 0 = { Name = .file Value = 0 SectionNumber = 65534 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_NULL (0) StorageClass = IMAGE_SYM_CLASS_FILE (103) NumberOfAuxSymbols = 1 AuxillaryData = 66 61 6B 65 00 00 00 00 - 00 00 00 00 00 00 00 00 |fake............| 00 00 |..| } 2 = { Name = _main Value = 0 SectionNumber = 1 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_FUNCTION (2) StorageClass = IMAGE_SYM_CLASS_EXTERNAL (2) NumberOfAuxSymbols = 1 AuxillaryData = 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................| 00 00 |..| } 4 = { Name = .text Value = 0 SectionNumber = 1 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_NULL (0) StorageClass = IMAGE_SYM_CLASS_STATIC (3) NumberOfAuxSymbols = 1 AuxillaryData = 20 00 00 00 02 00 00 00 - 00 00 00 00 00 00 00 00 | ...............| 00 00 |..| } 6 = { Name = .data Value = 0 SectionNumber = 2 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_NULL (0) StorageClass = IMAGE_SYM_CLASS_STATIC (3) NumberOfAuxSymbols = 1 AuxillaryData = 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................| 00 00 |..| } 8 = { Name = .bss Value = 0 SectionNumber = 3 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_NULL (0) StorageClass = IMAGE_SYM_CLASS_STATIC (3) NumberOfAuxSymbols = 1 AuxillaryData = 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................| 00 00 |..| } 10 = { Name = .weak._test_weak._main Value = 0 SectionNumber = 65535 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_NULL (0) StorageClass = IMAGE_SYM_CLASS_EXTERNAL (2) NumberOfAuxSymbols = 0 AuxillaryData = } 11 = { Name = _test_weak Value = 0 SectionNumber = 0 SimpleType = IMAGE_SYM_TYPE_NULL (0) ComplexType = IMAGE_SYM_DTYPE_NULL (0) StorageClass = IMAGE_SYM_CLASS_WEAK_EXTERNAL (105) NumberOfAuxSymbols = 1 AuxillaryData = 0A 00 00 00 01 00 00 00 - 00 00 00 00 00 00 00 00 |................| 00 00 |..| } ] } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Oct 10 02:45:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Oct 2010 02:45:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 8349] New: _Bool keyword is not defined in -fms-extensions Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8349 Summary: _Bool keyword is not defined in -fms-extensions Product: clang Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu The _Bool keyword isn't defined when in -fms-extensions mode. I know the reason is because one of the MS headers typedefs it, but this makes C99 code not work on Windows. I think that _Bool should always be a keyword, but allow typedefing it as a ms-extension. The typedef _must_ be: typedef bool _Bool; Anything else is an error. My reasoning for this is that extensions should be just that, extensions. No standard features should be removed when extensions are enabled. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Oct 10 13:20:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Oct 2010 13:20:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 8340] Is vector size zero allowed? In-Reply-To: References: Message-ID: <20101010182043.8CE962A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8340 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chris Lattner 2010-10-10 13:20:43 CDT --- Fixed in r116167 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Oct 10 13:22:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Oct 2010 13:22:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7854] User-definable arithmetic overflow handler In-Reply-To: References: Message-ID: <20101010182250.7D7A42A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7854 Eelis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Eelis 2010-10-10 13:22:49 CDT --- The new -ftrapv-handler in r114192 is exactly what I wanted, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Sun Oct 10 13:34:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Sun, 10 Oct 2010 13:34:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 8327] LLVM miscompiles va_arg() on 64-bit PowerPC, truncating address to 32 bits In-Reply-To: References: Message-ID: <20101010183415.E42C92A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8327 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-10-10 13:34:15 CDT --- Fixed in r116168 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 02:11:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 02:11:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 8350] New: Clang does not produce symbols for typeinfo Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8350 Summary: Clang does not produce symbols for typeinfo Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: packadal at gmail.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Hi, I have been trying clang on my project for some time now, and I have come with a set of patches to make it compile successfully. Clang produces nice error messages and I'd really be able to use it as my default compiler. However, I have a link error to typeinfo for two classes. These classes inherit from a template class, laid out as follows: template class Base : public SubBase { virtual void Foo(); }; #include "Base.cxx" //Base.cxx template Base::Foo() { .... } I moved the definitions into the header file, and the linker error disappeared. However, the strange thing is that this base template class is used in 10 different instances, and only 2 cause link errors, so there might be more to it that I can see. The project I work on is open-source, and you can get the sources and try this by yourself (however the patches to get it to compile with clang are not in yet, so I'll attach them here if you want me to). svn repo: https://auber.svn.sourceforge.net/svnroot/auber/tulip/trunk website: http://www.tulip-software.org Best regards -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 08:12:07 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 08:12:07 -0500 (CDT) Subject: [LLVMbugs] [Bug 8351] New: void LLVMAddLoopIndexSplitPass(LLVMPassManagerRef PM) is still in llvm-c/Transforms/Scalar.h Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8351 Summary: void LLVMAddLoopIndexSplitPass(LLVMPassManagerRef PM) is still in llvm-c/Transforms/Scalar.h Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: vslugovsky at gmail.com CC: llvmbugs at cs.uiuc.edu The LoopIndexSplit pass does not exist any longer, but it's still referenced from an llvm-c header, which breaks an automatic API generation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 11:42:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 11:42:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 8352] New: llc emits improper .comm for PECOFF Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8352 Summary: llc emits improper .comm for PECOFF Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu $ echo '@foo = common global i32 0, align 4' | Release+Asserts/bin/llc.exe -mtriple=i686-cygwin .comm _foo,4,2 # @foo # @foo $ echo '@foo = common global i32 0, align 4' | Release+Asserts/bin/llc.exe -mtriple=i686-cygwin | as {standard input}: Assembler messages: {standard input}:1: Error: junk at end of line, first unrecognized character is `,' -- It is valid; $ echo '.comm _foo,4' | as -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 12:11:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 12:11:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 8353] New: r115248 break generation of debugging info for obj-C ivars Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8353 Summary: r115248 break generation of debugging info for obj-C ivars Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen AssignedTo: unassignedclangbugs at nondot.org ReportedBy: devlists at shadowlab.org CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5601) --> (http://llvm.org/bugs/attachment.cgi?id=5601) Sample The attempt to fix rdar://8493239 in r115248 breaks generation of debugging informations for Obj-C ivars. For the record: ------------------------ r115248 - 02:01 - fjahanian Output debug info. for ivars declared in class extension and implementation. Fixes rdar://8493239 ------------------------ After this change, all ivars are declared in dwarf as having the same offset, and so the debugger display wrong information. You can easily show the bug in the attached archive. Just compare foo_x86.s generated using clang rev 115247 and r115248. The only differences are clang revision and the ivar offsets in dwarfs info. Ditto for foo_x86_64.s. Maybe removing the test was not the good way to fix the problem ;-) ------------------------ r115258 - 03:01 - fjahanian Remove test until further notice. D /cfe/trunk/test/CodeGenObjC/debug-info-default-synth-ivar.m ------------------------ -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 12:19:46 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 12:19:46 -0500 (CDT) Subject: [LLVMbugs] [Bug 8354] New: MC-COFF: Don't emit local storage with .bss$linkonce Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8354 Summary: MC-COFF: Don't emit local storage with .bss$linkonce Product: libraries Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu .bss$linkonce_foobar would be unified by linker. static and anonymous variables should not emitted to linkonce. //////// foo.cc int foo; static int bar; namespace { int qux; static int quux; } void fooset(int a0, int a1, int a2, int a3) { foo = a0; bar = a1; qux = a2; quux = a3; } int fooget() { return foo + bar + qux + quux; } //////// bar.cc extern int foo; static int bar; namespace { int qux; static int quux; } void barset(int a0, int a1, int a2, int a3) { foo = a0; bar = a1; qux = a2; quux = a3; } int barget() { return foo + bar + qux + quux; } ======== $ clang++ -O3 -S -emit-llvm foo.cc -o foo.ll (snip) @foo = global i32 0, align 4 @_ZL3bar = internal global i32 0, align 4 @_ZN12_GLOBAL__N_13quxE = internal global i32 0, align 4 @_ZN12_GLOBAL__N_1L4quuxE = internal global i32 0, align 4 $ clang++ -O3 -S -emit-llvm bar.cc -o bar.ll (snip) @foo = external global i32 @_ZL3bar = internal global i32 0, align 4 @_ZN12_GLOBAL__N_13quxE = internal global i32 0, align 4 @_ZN12_GLOBAL__N_1L4quuxE = internal global i32 0, align 4 ======== $ llc -filetype=obj foo.ll $ llc -filetype=obj bar.ll $ ld foo.o bar.o -o foobar.exe $ objdump -h foobar.exe Sections: Idx Name Size VMA LMA File off Algn 0 .text 000000a8 00401000 00401000 00000400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000004 00402000 00402000 00000600 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000000c 00403000 00403000 00000000 2**2 ALLOC 3 .idata 00000014 00404000 00404000 00000800 2**2 CONTENTS, ALLOC, LOAD, DATA !!! size of .bss should be 0x18(4 * 6)! $ nm -n --demangle foobar.exe 00402000 D _data_start__ 00402000 D foo 00402004 D _data_end__ 00403000 B _bss_start__ 00403000 B _bss_end__ 00403000 b .bss$linkonce__ZL3bar 00403000 b bar 00403004 b .bss$linkonce__ZN12_GLOBAL__N_13quxE 00403004 b (anonymous namespace)::qux 00403008 b .bss$linkonce__ZN12_GLOBAL__N_1L4quuxE 00403008 b (anonymous namespace)::quux -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 12:44:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 12:44:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8351] void LLVMAddLoopIndexSplitPass(LLVMPassManagerRef PM) is still in llvm-c/Transforms/Scalar.h In-Reply-To: References: Message-ID: <20101011174433.9B6BB2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8351 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Chris Lattner 2010-10-11 12:44:33 CDT --- Removed in r116209, thanks. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 13:01:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 13:01:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8355] New: clang++ generates incorrect code if multiple classes with the same name are defined in the same function Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8355 Summary: clang++ generates incorrect code if multiple classes with the same name are defined in the same function Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: richard-llvm at metafoo.co.uk CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang++ generates incorrect code if two classes are defined with the same name within a function. Specifically, the constructors for both classes use the first class's vtable. Consider the following code: #include struct I { virtual void F() const = 0; }; void Go(const I &i) { i.F(); } int main() { if (true) { struct C : I { void F() const { std::cout << "A" << std::endl; } }; Go(C()); } if (true) { struct C : I { void F() const { std::cout << "B" << std::endl; } }; Go(C()); } } Under g++ and other compilers, this prints: A B Under clang++, it prints: A A -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 13:24:52 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 13:24:52 -0500 (CDT) Subject: [LLVMbugs] [Bug 8356] New: Don't do unprofitable narrowing of loads. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8356 Summary: Don't do unprofitable narrowing of loads. Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: jpbonn-keyword-llvmbug.a51747 at corniceresearch.com CC: llvmbugs at cs.uiuc.edu Our backend only does 32 bit loads. I noticed some loads were narrowed to 8 bits and then had to be reverted back to 32 bit loads. This patch prevents the initial lowering. I've only tested this on my backend. Index: CodeGen/SelectionDAG/TargetLowering.cpp =================================================================== --- CodeGen/SelectionDAG/TargetLowering.cpp (revision 115815) +++ CodeGen/SelectionDAG/TargetLowering.cpp (working copy) @@ -1899,7 +1899,9 @@ else bestOffset = (uint64_t)offset * (width/8); bestMask = Mask.lshr(offset * (width/8) * 8); - bestWidth = width; + EVT NewVT = EVT::getIntegerVT(*DAG.getContext(), width); + if (isNarrowingProfitable(Lod->getMemoryVT(), NewVT)) + bestWidth = width; break; } newMask = newMask << width; -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 14:05:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 14:05:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8297] machine licm crash on atomic cmpswap i64 In-Reply-To: References: Message-ID: <20101011190529.AB2022A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8297 Andrew Trick changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Andrew Trick 2010-10-11 14:05:29 CDT --- Fixed in 116214. Test case test/CodeGen/X86/2010-10-08-cmpxchg8b.ll -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 14:53:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 14:53:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8357] New: Crash inside fast register allocator on PowerPC Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8357 Summary: Crash inside fast register allocator on PowerPC Product: new-bugs Version: trunk Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: nwhitehorn at freebsd.org CC: llvmbugs at cs.uiuc.edu With r116206, running llc on the attached IR causes an UNREACHABLE to be reached: llc vatest.ll -o foo.s -regalloc=fast -march=ppc32 UNREACHABLE executed! Stack dump: 0. Program arguments: llc vatest.ll -regalloc=fast -march=ppc32 1. Running pass 'Function Pass Manager' on module 'vatest.ll'. 2. Running pass 'Fast Register Allocator' on function '@testing' Abort trap: 6 (core dumped) This seems to be appear only when targeting ppc32, and is a regression relative to last week. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 15:43:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 15:43:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 8357] Crash inside fast register allocator on PowerPC In-Reply-To: References: Message-ID: <20101011204340.BA48E2A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8357 Jakob Stoklund Olesen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jakob Stoklund Olesen 2010-10-11 15:43:40 CDT --- Fixed in r116222. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 16:58:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 16:58:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 8352] llc emits improper .comm for PECOFF In-Reply-To: References: Message-ID: <20101011215811.BBB4D2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8352 Anton Korobeynikov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |asl at math.spbu.ru Resolution| |INVALID --- Comment #2 from Anton Korobeynikov 2010-10-11 16:58:11 CDT --- (In reply to comment #1) > $ as --version > GNU assembler (GNU Binutils) 2.19.1 > > Is it older? Yes. Read http://llvm.org/docs/GettingStarted.html#pf_8 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 18:56:55 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 18:56:55 -0500 (CDT) Subject: [LLVMbugs] [Bug 8353] r115248 break generation of debugging info for obj-C ivars In-Reply-To: References: Message-ID: <20101011235655.329B22A6C130@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8353 Fariborz Jahanian changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Fariborz Jahanian 2010-10-11 18:56:54 CDT --- Fixed in r116273. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 21:01:45 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 21:01:45 -0500 (CDT) Subject: [LLVMbugs] [Bug 8358] New: [cygwin] sys::Program::Execute should use spawn Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8358 Summary: [cygwin] sys::Program::Execute should use spawn Product: libraries Version: 1.0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: System Library AssignedTo: unassignedbugs at nondot.org ReportedBy: clattner at apple.com CC: llvmbugs at cs.uiuc.edu "fork" on cygwin is a horrible hack. Apparently the solution is to use the cygwin spawn function which is both more efficient and also more reliable. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Mon Oct 11 22:59:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Mon, 11 Oct 2010 22:59:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 8359] New: ARM allocates invalid registers for VFPv3-D16 (possibly allocating D16, D17 etc.) Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8359 Summary: ARM allocates invalid registers for VFPv3-D16 (possibly allocating D16, D17 etc.) Product: tools Version: trunk Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P Component: llc AssignedTo: unassignedbugs at nondot.org ReportedBy: jvoung at google.com CC: llvmbugs at cs.uiuc.edu The ARM backend may end up allocating registers D16 to D31 when "-mattr=+vfp3" is specified. However, this will not work for hardware that only supports 16 registers. Attached is a possible fix, adding a new flag to support -"mattr=+vfp3,+d16". -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 02:55:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 02:55:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8360] New: Resolve call to atoi with constant input at compile time. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8360 Summary: Resolve call to atoi with constant input at compile time. Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations AssignedTo: unassignedbugs at nondot.org ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu Ran into this while trying to get LLVM to not optimize away my contrived code. Seems like an easy SimplifyLibCalls opt to implement to get used to transforms. Filing this so I don't forget. atoi("42") -> i32 42 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 08:22:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 08:22:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 8361] New: duplicated compare instruction Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8361 Summary: duplicated compare instruction Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: Edmund.Grimley-Evans at arm.com CC: llvmbugs at cs.uiuc.edu Keywords: duplicate duplicated redundant repeated compare comparison cmp The compare instruction is repeated unnecessarily in the code generated from this: const char *f(int x, int y) { return x < y ? "<" : x == y ? "=" : ">"; } I've seen this with the ARM and x86 back ends. Currently on r116298. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 08:25:57 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 08:25:57 -0500 (CDT) Subject: [LLVMbugs] [Bug 8362] New: Ran out of registers during register allocation! Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8362 Summary: Ran out of registers during register allocation! Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5606) --> (http://llvm.org/bugs/attachment.cgi?id=5606) testcase GCC can compile the attached asm, but llvm-gcc says: $ llvm-gcc -S pr21291.c cc1: error in backend: Ran out of registers during register allocation! Please check your inline asm statement for invalid constraints: INLINEASM , 0, 10, %reg16392, 10, %reg16393, 10, %reg16394, 10, %reg16395, 14, %EDI, 44, , 1, %reg0, 0, %reg0, 2147483657, %ECX, 2147549193, %EBX, 2147614729, %ESI, 2147680265, %reg16395, 14, %EFLAGS, 14, %EDX, 14, %EAX; GR32:%reg16392,16393,16394,16395,16395 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 09:10:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 09:10:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 8363] New: Assertion `PartVT.isInteger() && ValueVT.isInteger() && "Unknown mismatch!"' failed Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8363 Summary: Assertion `PartVT.isInteger() && ValueVT.isInteger() && "Unknown mismatch!"' failed Product: new-bugs Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: baldrick at free.fr CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5607) --> (http://llvm.org/bugs/attachment.cgi?id=5607) testcase .ll $ llc part.ll llc: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:330: void getCopyToParts(llvm::SelectionDAG&, llvm::DebugLoc, llvm::SDValue, llvm::SDValue*, unsigned int, llvm::EVT, llvm::ISD::NodeType): Assertion `PartVT.isInteger() && ValueVT.isInteger() && "Unknown mismatch!"' failed. ... 8 llc 0x00000000008baf2d llvm::SelectionDAGBuilder::visitInlineAsm(llvm::ImmutableCallSite) + 14557 9 llc 0x00000000008c9dfc llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 572 10 llc 0x00000000008b31ca llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 394 11 llc 0x00000000008d922d llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 45 12 llc 0x00000000008e7510 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 160 13 llc 0x00000000008e7b74 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1476 14 llc 0x00000000008e882b llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 491 15 llc 0x0000000000cb65bd llvm::FPPassManager::runOnFunction(llvm::Function&) + 557 16 llc 0x0000000000cb66bb llvm::FPPassManager::runOnModule(llvm::Module&) + 75 17 llc 0x0000000000cb6147 llvm::MPPassManager::runOnModule(llvm::Module&) + 503 18 llc 0x0000000000cb62c7 llvm::PassManagerImpl::run(llvm::Module&) + 167 19 llc 0x000000000051c335 main + 4117 20 libc.so.6 0x00007f3d774e8d8e __libc_start_main + 254 21 llc 0x000000000051a709 Stack dump: 0. Program arguments: llc part.ll 1. Running pass 'Function Pass Manager' on module 'part.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@f4' Aborted -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 11:23:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 11:23:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8359] ARM allocates invalid registers for VFPv3-D16 (possibly allocating D16, D17 etc.) In-Reply-To: References: Message-ID: <20101012162308.0E1442A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8359 Bob Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bob.wilson at apple.com Resolution| |FIXED --- Comment #2 from Bob Wilson 2010-10-12 11:23:07 CDT --- Patch applied in svn 116310. Thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 12:05:34 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 12:05:34 -0500 (CDT) Subject: [LLVMbugs] [Bug 7715] clang++ gives wrong error about default argument in kdatetime.h In-Reply-To: References: Message-ID: <20101012170534.B45A22A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7715 Manuel Klimek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Manuel Klimek 2010-10-12 12:05:34 CDT --- Fixed in r116311. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 13:28:22 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 13:28:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 6568] Assertion failed: Default argument is not yet parsed! In-Reply-To: References: Message-ID: <20101012182822.655922A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6568 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-10-12 13:28:20 CDT --- Fixed in Clang r116324. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 13:28:24 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 13:28:24 -0500 (CDT) Subject: [LLVMbugs] [Bug 8245] Assertion failed: Default argument is not yet parsed! In-Reply-To: References: Message-ID: <20101012182824.8026A2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8245 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-12 13:28:23 CDT --- Fixed in Clang r116324. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 13:58:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 13:58:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 8364] New: Verifier doesn't flag out-of-module constants, BC writing crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8364 Summary: Verifier doesn't flag out-of-module constants, BC writing crashes Product: libraries Version: 2.7 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes AssignedTo: unassignedbugs at nondot.org ReportedBy: clemahieu at gmail.com CC: llvmbugs at cs.uiuc.edu BitCode generation fails with "Unknown constant!" "UNREACHABLE executed at BitcodeWriter.cpp:895 Issue can be reproduced with the following: llvm::LLVMContext ctx; llvm::StringRef mn1 ("m1"); llvm::StringRef mn2 ("m2"); llvm::Module m1 (mn1, ctx); llvm::Module m2 (mn2, ctx); const llvm::Type * rt = llvm::Type::getVoidTy (ctx); const llvm::FunctionType * ft = llvm::FunctionType::get (rt, false); llvm::Function * f1 = llvm::Function::Create (ft, llvm::GlobalValue::ExternalLinkage); m1.getFunctionList ().push_back (f1); const llvm::IntegerType * it = llvm::IntegerType::get (ctx, 8); const llvm::PointerType * pt = llvm::PointerType::get (it, 0); const llvm::Constant * ce = llvm::ConstantExpr::getBitCast (f1, pt); llvm::Constant * v [1] = {(llvm::Constant *)ce}; const llvm::ArrayType * at = llvm::ArrayType::get (pt, 1); const llvm::Constant * a = llvm::ConstantArray::get (at, v, 1); const llvm::Type * gt = a->getRawType (); llvm::GlobalVariable * g = new llvm::GlobalVariable (gt, true, llvm::GlobalValue::ExternalLinkage, (llvm::Constant *)a); m2.getGlobalList ().push_back (g); std::string message; bool result = llvm::verifyModule (m2, llvm::ReturnStatusAction, &message); -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 14:44:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 14:44:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 8365] New: Output of "llc -filetype=obj" != llvm-mc Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8365 Summary: Output of "llc -filetype=obj" != llvm-mc Product: libraries Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: rafael.espindola at gmail.com CC: llvmbugs at cs.uiuc.edu This is a fun case. When doing the codegen of define i64 @bra(i32 %zed) nounwind { %t1 = zext i32 %zed to i64 %t2 = and i64 %t1, 4294967232 ret i64 %t2 } The isel dag will contain the i64 constant 4294967232. During the selection we decide to use a 32 "and" and produce a i32 target constant of -64. Unfortunately, we fail to noticed that it will fit in 8 bits and select an AND32ri. The produced assembly is andl $-64, %edi # encoding: [0x81,0xe7,0xc0,0xff,0xff,0xff] movl %edi, %eax # encoding: [0x89,0xf8] ret # encoding: [0xc3] When this gets passed to MC it finds that -64 fits in 8 bits and uses a AND32ri8. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 15:27:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 15:27:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 8366] New: -march=native on i5 emits unaligned movaps Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8366 Summary: -march=native on i5 emits unaligned movaps Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: astrange at ithinksw.com CC: llvmbugs at cs.uiuc.edu Using llvm r116113/clang r116082. The attached file contains several unaligned movaps when compiled with -march=native on i5, but not without it. > clang -O3 -march=native -S demux_movaps_unaligned.i -v clang version 2.9 (git://repo.or.cz/clang.git 43fb14bb9982c4c59cfd0d9e195e52145c3f62ef) Target: x86_64-apple-darwin10 Thread model: posix "/usr/local/llvm/bin/clang" -cc1 -triple x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name demux_movaps_unaligned.i -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu corei7 -target-linker-version 97.14 -v -resource-dir /usr/local/llvm/lib/clang/2.9 -O3 -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o demux_movaps_unaligned.s -x cpp-output demux_movaps_unaligned.i clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-apple-darwin10 #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/llvm/lib/clang/2.9/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. > grep movaps demux_movaps_unaligned.s movaps %xmm0, -120(%rbp) movaps %xmm0, -136(%rbp) <-- movaps %xmm0, -152(%rbp) <-- movaps %xmm0, -424(%rbp) movaps %xmm0, -440(%rbp) movaps %xmm0, -456(%rbp) movaps %xmm0, -280(%rbp) movaps %xmm0, -296(%rbp) movaps %xmm0, -312(%rbp) movaps %xmm0, -136(%rbp) movaps %xmm0, -152(%rbp) movaps %xmm0, -168(%rbp) <-- movaps %xmm0, (%rax) This causes mplayer to immediately crash in new_demuxer() when compiled with -march=native. Un-minimized source attached. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 15:32:56 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 15:32:56 -0500 (CDT) Subject: [LLVMbugs] [Bug 8325] Error on throwing pointer to pointee with non public destructor In-Reply-To: References: Message-ID: <20101012203256.55F6E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8325 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |sharparrow1 at yahoo.com Resolution| |FIXED --- Comment #2 from Eli Friedman 2010-10-12 15:32:55 CDT --- r116336. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 18:28:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 18:28:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 7305] plugins should take parameters In-Reply-To: References: Message-ID: <20101012232833.70B772A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7305 Tobias Grosser changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |grosser at fim.uni-passau.de Resolution| |FIXED --- Comment #5 from Tobias Grosser 2010-10-12 18:28:32 CDT --- Was applied in r106113. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 18:44:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 18:44:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8367] New: clang-compiled libtheora dump_video segfaults on test clips Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8367 Summary: clang-compiled libtheora dump_video segfaults on test clips Product: clang Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: me at endeavour.zapto.org CC: llvmbugs at cs.uiuc.edu Hi, When llvm & clang (r116318) on Mac OSX 10.5 (Darwin 9.8.0) / PowerPC are used to compile libtheora v1.1.1, the resulting example decoder (examples/dump_video.c) segfaults on any theora videos. The same is not true of dump_video compiled with Apple gcc 4.0.1. -- vs -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 19:28:31 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 19:28:31 -0500 (CDT) Subject: [LLVMbugs] [Bug 6784] C++98/03: Template arguments cannot be unnamed types In-Reply-To: References: Message-ID: <20101013002831.349822A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6784 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Douglas Gregor 2010-10-12 19:28:30 CDT --- Fixed in Clang r116382. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 21:16:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 21:16:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8313] Use after free in the linker In-Reply-To: References: Message-ID: <20101013021614.C50C12A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8313 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #16 from Rafael ?vila de Esp?ndola 2010-10-12 21:16:14 CDT --- Fixed in r116390 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 21:47:01 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 21:47:01 -0500 (CDT) Subject: [LLVMbugs] [Bug 8368] New: Compiler getting confused when using templated function from the return value of a function of a member Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8368 Summary: Compiler getting confused when using templated function from the return value of a function of a member Product: clang Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: psycocyril at yahoo.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The following code fails to compile (see comments) namespace bug { class A { public: template T foo(void) const; }; class B { public: A& get_A() const; }; template class C { private: B & m_b; public: C(B & b) : m_b(b) { } int bar(void) { return m_b.get_A().foo(); // fails with: // error: use 'template' keyword to treat 'foo' as a dependent template name // return m_b.get_A().foo(); // ^ // template // works with: //A& a= m_b.get_A(); //return a.foo(); } }; } -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 22:42:54 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 22:42:54 -0500 (CDT) Subject: [LLVMbugs] [Bug 8367] clang-compiled libtheora dump_video segfaults on test clips In-Reply-To: References: Message-ID: <20101013034254.33EB02A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8367 Chris Lattner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER --- Comment #1 from Chris Lattner 2010-10-12 22:42:53 CDT --- Clang/powerpc isn't supported at the moment, there are lots of known bugs. Before individual bugs are filed, we really need someone to take and own darwin/ppc support for clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 23:20:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 23:20:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8369] New: Support mregparm flag Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8369 Summary: Support mregparm flag Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alp at nuanti.com CC: llvmbugs at cs.uiuc.edu Blocks: 4068 -mregparm: Control the number registers used to pass integer arguments. This flag is often used to override the ABI-specified regparm value throughout a compilation unit. clang already supports target-specific values for this provided by TargetInfo, and also by use of attributes, but the frontend doesn't support this as a user-specified compiler flag yet. Ignoring this is often harmless (used only for optimization) but certain code such as that in the Linux kernel boot module using .code16gcc inline ASM relies on mregparm working correctly. This probably needs to be handled at a higher level than IRgen as Sema performs checking and comparison of function regparm attributes. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Tue Oct 12 23:45:16 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Tue, 12 Oct 2010 23:45:16 -0500 (CDT) Subject: [LLVMbugs] [Bug 8370] New: Seemingly incorrect output on Windows for the exact same generated X86 assembly as Linux. Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8370 Summary: Seemingly incorrect output on Windows for the exact same generated X86 assembly as Linux. Product: libraries Version: trunk Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: X86 AssignedTo: unassignedbugs at nondot.org ReportedBy: bigcheesegs at gmail.com CC: llvmbugs at cs.uiuc.edu This is from test-suite/SingleSource/UnitTests/Vetor/sumarray-dbl.c. Attached files: * test.ll - The LLVM IR generated by clang when targeting both platforms (I ran clang on Linux and Windows, but they produced the same output). * test-lin.asm - The X86 assembly generated by clang -S on Linux. * test-win.asm - The X86 assembly generated by clang -S on Windows. The command used was: % clang sumarray-dbl.c -O3 -fomit-frame-pointer -march=i386 I added -march because one cpu is some old crappy one and the other is an i7, so they were using different methods. When the resulting program is run on Linux, the output is as expected (or at least the same as the reference output): 488862 490096 491331 492566 493800 495035 496269 497504 However, on Windows, the output is: 488862 490097 491331 492566 493800 495035 496269 497504 The only difference is that the second number is 1 larger. I get the exact same result if I use -march=native. This really just looks like a rounding issue, but I want to make sure there isn't a larger issue. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 04:42:35 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 04:42:35 -0500 (CDT) Subject: [LLVMbugs] [Bug 8371] New: __attribute__ ((__const)) not recognized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8371 Summary: __attribute__ ((__const)) not recognized Product: clang Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: ggreif at gmail.com CC: llvmbugs at cs.uiuc.edu We seem to have a legacy header (and no process in place to change it) which looks pretty much like this: http://en.wikibooks.org/wiki/C++_Programming/ctype.h_header Clang warns on the "__attribute__ ((__const))" part: warning: unknown attribute '__const' ignored [-Wunknown-attributes] __attribute__ ((__const)); ^ I propose to add '__const' as an attribute, becoming synonymous to 'const'. I am about to make a patch and shall attach it here. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 07:59:26 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 07:59:26 -0500 (CDT) Subject: [LLVMbugs] [Bug 8372] New: clang::DiagnosticInfo::getArgKind(unsigned int) fails assertion Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8372 Summary: clang::DiagnosticInfo::getArgKind(unsigned int) fails assertion Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: hans at chromium.org CC: llvmbugs at cs.uiuc.edu template void Foo () { } void Bar () { Foo <0x80000000> (); } triggers the following assert when trying to compile with Clang built from trunk r116802: /tmp/a.cc:5:8: warning: clang: /work/llvm/tools/clang/lib/Basic/../../include/clang/Basic/Diagnostic.h:864: clang::Diagnostic::ArgumentKind clang::DiagnosticInfo::getArgKind(unsigned int) const: Assertion `Idx < getNumArgs() && "Argument index out of range!"' failed. (Stack trace attached.) This seems to be a regression from r116058, where the code compiles. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 08:32:20 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 08:32:20 -0500 (CDT) Subject: [LLVMbugs] [Bug 8365] Output of "llc -filetype=obj" != llvm-mc In-Reply-To: References: Message-ID: <20101013133220.B69A02A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8365 Rafael ?vila de Esp?ndola changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Rafael ?vila de Esp?ndola 2010-10-13 08:32:20 CDT --- Fixed in 116403. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 12:24:36 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 12:24:36 -0500 (CDT) Subject: [LLVMbugs] [Bug 8372] clang::DiagnosticInfo::getArgKind(unsigned int) fails assertion In-Reply-To: References: Message-ID: <20101013172436.E8CDE2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8372 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Douglas Gregor 2010-10-13 12:24:36 CDT --- Fixed in Clang r116411, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 15:01:13 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 15:01:13 -0500 (CDT) Subject: [LLVMbugs] [Bug 7388] Error using _Bool as a template argument In-Reply-To: References: Message-ID: <20101013200113.D09B92A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7388 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-10-13 15:01:12 CDT --- Fixed in Clang r116422. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 15:02:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 15:02:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 8349] _Bool keyword is not defined in -fms-extensions In-Reply-To: References: Message-ID: <20101013200202.70A6A2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8349 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dgregor at apple.com Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-13 15:02:01 CDT --- The real issue here is that _Bool shouldn't be defined in C++ mode. Fixed in Clang r116422. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 15:42:33 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 15:42:33 -0500 (CDT) Subject: [LLVMbugs] [Bug 8328] Unable to call method of incomplete class In-Reply-To: References: Message-ID: <20101013204233.D82762A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8328 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-13 15:42:33 CDT --- Fixed in Clang r116429. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 17:20:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 17:20:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8159] clang accepts redundant scope specifier for variables in class definition In-Reply-To: References: Message-ID: <20101013222044.322F12A6C12F@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8159 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-13 17:20:43 CDT --- Fixed in Clang r116445. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 17:55:41 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 17:55:41 -0500 (CDT) Subject: [LLVMbugs] [Bug 8168] Clang accepts static functions that would override virtual ones In-Reply-To: References: Message-ID: <20101013225541.785232A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8168 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-13 17:55:41 CDT --- Fixed in Clang r8168. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 18:20:43 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 18:20:43 -0500 (CDT) Subject: [LLVMbugs] [Bug 8373] New: diagnose use of base member before base is initialized Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8373 Summary: diagnose use of base member before base is initialized Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Created an attachment (id=5616) --> (http://llvm.org/bugs/attachment.cgi?id=5616) full program testcase The attached testcase is a fully executable version of this snippet: struct Base { explicit Base(int) { } int member_; }; struct Derived : public Base { Derived() : Base(member_) { } }; I think there should be a warning on use of member_ in Derived because it hasn't been initialized yet. None of clang, gcc nor EDG warn on this. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Wed Oct 13 20:10:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Wed, 13 Oct 2010 20:10:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8374] New: Generalize clang blocks to support other closure-like language features Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8374 Summary: Generalize clang blocks to support other closure-like language features Product: clang Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++0x AssignedTo: unassignedclangbugs at nondot.org ReportedBy: alp at nuanti.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com clang Sema and IRgen support for the Apple blocks extension can be reworked to provide a general-purpose backend for closure-style language constructs. In particular, Apple blocks (a) share many characteristics with (b) GNU nested functions and (c) C++0x lambdas: * IRgen to privately linked LLVM function: a, b, c * Capture of locals by reference: a, b, c * Capture of locals by value: a, c * Permits taking address-of-function: a, b (often with undefined behavour), c It should be possible to support GNU nested functions with a one-line modification to the parser and potentially no new AST classes, while C++0x lambda support will require a little additional parser support and new Stmt/Decl classes. While nested functions aren't a high priority, re-using Blocks IRgen would get us support for this GNU feature with little effort while providing more complete coverage of the gcc DG test suite, which tests many unrelated language features using nested functions for scoping brevity. C++0x lambdas on the other hand are a popular upcoming feature already supported by VC++. The blocks code can be easily modified to cover most of the semantic analysis and codegen required by the standard for lambdas. Ditto for the static analyzer. Another motivation for generalising the blocks code is to audit the following: 1) BlockDeclRefExpr: Would it be possible to just use ordinary DeclRefExprs for a more consistent AST? 2) BlockDecl: This shares a lot in common with FunctionDecl and ObjCMethodDecl. Would it be possible to factor out shared functionality into a common base? 3) Overloaded "Block" terminology in clang internals is confusing to developers. isBlockScope(), isBlockVarDecl(): Trying to figure out whether functions like this refer to Apple blocks or C statement blocks {} is guesswork for anyone. "Block" already has a single, clear meaning to most compiler developers while Apple "Blocks" are really just a marketing term for a specific flavour of closures. Let's make this clear at the source level. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 07:05:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 07:05:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 8375] New: Symbol is undefined when LLVM built by CMake Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8375 Summary: Symbol is undefined when LLVM built by CMake Product: libraries Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: System Library AssignedTo: unassignedbugs at nondot.org ReportedBy: oroppas at gmail.com CC: llvmbugs at cs.uiuc.edu I built LLVM from trunk using CMake and everything went all well. Next, I successfully built dragonegg from trunk. Then, re-building dragonegg itself using dragonegg plugin ended up with the error: cc1plus: error: Cannot load plugin ./dragonegg.so /usr/lib/libLLVMSystem.so: undefined symbol: pthread_mutex_trylock Should llvm/lib/System/CMakeLists.txt have the lines like if( HAVE_LIBPTHREAD ) target_link_libraries(LLVMSystem pthread) endif( HAVE_LIBPTHREAD ) ? -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 07:21:21 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 07:21:21 -0500 (CDT) Subject: [LLVMbugs] [Bug 8376] New: LinkModules: "alias bitcast" causes assertion failure Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8376 Summary: LinkModules: "alias bitcast" causes assertion failure Product: libraries Version: trunk Platform: All OS/Version: All Status: NEW Severity: normal Priority: P Component: Linker AssignedTo: unassignedbugs at nondot.org ReportedBy: geek4civic at gmail.com CC: llvmbugs at cs.uiuc.edu Similar to PR6925, but I think it is another issue, to prevent clang++ -mconstructor-aliases LTO. ; a.ll declare void @b(i8*) @va = constant void(i8*)* @b ; b8.ll declare void @b8(i8*) @b = alias void(i8*)* @b8 ; b32.ll declare void @b32(i32*) @b = alias bitcast(void (i32*)* @b32 to void (i8*)*) $ Release+Asserts/bin/llvm-link a.ll b8.ll -o ab8 (passes) $ Release+Asserts/bin/llvm-link a.ll b32.ll -o ab32 llvm-link: /home/chapuni/llvm/lib/VMCore/Globals.cpp:230: llvm::GlobalAlias::GlobalAlias(const llvm::Type*, llvm::GlobalValue::LinkageTypes, const llvm::Twine&, llvm::Constant*, llvm::Module*): Assertion `aliasee->getType() == Ty && "Alias and aliasee types should match!"' failed. 0 llvm-link 0x000000000058c08f 1 llvm-link 0x000000000058e352 2 libpthread.so.0 0x00000039de00eb10 3 libc.so.6 0x00000039dd430265 gsignal + 53 4 libc.so.6 0x00000039dd431d10 abort + 272 5 libc.so.6 0x00000039dd4296e6 __assert_fail + 246 6 llvm-link 0x00000000004d35f0 7 llvm-link 0x000000000044a2cb 8 llvm-link 0x000000000044d967 9 llvm-link 0x000000000040aecb main + 315 10 libc.so.6 0x00000039dd41d994 __libc_start_main + 244 11 llvm-link 0x000000000040a2f9 Stack dump: 0. Program arguments: Release+Asserts/bin/llvm-link a.ll b32.ll -o ab32.bc Aborted -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 08:21:49 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 08:21:49 -0500 (CDT) Subject: [LLVMbugs] [Bug 8376] LinkModules: "alias bitcast" causes assertion failure In-Reply-To: References: Message-ID: <20101014132149.C8A882A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8376 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |geek4civic at gmail.com Resolution| |DUPLICATE --- Comment #1 from NAKAMURA Takumi 2010-10-14 08:21:49 CDT --- Why I didn't find PR8300 with keywords "alias aliasee"? *** This bug has been marked as a duplicate of bug 8300 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 10:31:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 10:31:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8377] New: Assertion `Rep && "no type provided!"' on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8377 Summary: Assertion `Rep && "no type provided!"' on invalid code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The code: template struct def_helper { void def_maybe_overloads( ) { ,def_helper } }; Produces the following backtrace on clang version 2.9 (trunk 116475) Target: x86_64-unknown-linux-gnu Thread model: posix clang++ t.cc -c t.cc:4:3: error: expected expression ,def_helper ^ t.cc:4:15: error: template argument for non-type template parameter must be an expression ,def_helper ^~~ t.cc:1:14: note: template parameter is declared here template ^ clang: DeclSpec.cpp:298: bool clang::DeclSpec::SetTypeSpecType(clang::TypeSpecifierType, clang::SourceLocation, const char*&, unsigned int&, clang::ParsedType): Assertion `Rep && "no type provided!"' failed. 0 clang 0x000000000165139f 1 clang 0x0000000001653612 2 libpthread.so.0 0x00007f0e453108f0 3 libc.so.6 0x00007f0e445ffa75 gsignal + 53 4 libc.so.6 0x00007f0e446035c0 abort + 384 5 libc.so.6 0x00007f0e445f8941 __assert_fail + 241 6 clang 0x00000000008d1330 clang::DeclSpec::SetTypeSpecType(clang::TypeSpecifierType, clang::SourceLocation, char const*&, unsigned int&, clang::OpaquePtr) + 144 7 clang 0x00000000008baf31 clang::Parser::ParseCXXSimpleTypeSpecifier(clang::DeclSpec&) + 913 8 clang 0x00000000008b49f2 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 258 9 clang 0x00000000008b59aa clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 42 10 clang 0x00000000008b51db clang::Parser::ParseCastExpression(bool, bool, bool&, clang::OpaquePtr) + 2283 11 clang 0x00000000008b59aa clang::Parser::ParseCastExpression(bool, bool, clang::OpaquePtr) + 42 12 clang 0x00000000008b679e clang::Parser::ParseAssignmentExpression() + 30 13 clang 0x00000000008b5bf3 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) + 515 14 clang 0x00000000008b6c89 clang::Parser::ParseExpression() + 25 15 clang 0x00000000008913da clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 442 16 clang 0x0000000000891cf4 clang::Parser::ParseCompoundStatementBody(bool) + 404 17 clang 0x0000000000892336 clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 118 18 clang 0x00000000008cadfa clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 426 19 clang 0x00000000008c927c clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 124 20 clang 0x00000000008b1db4 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 2020 21 clang 0x00000000008b2ad0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 2800 22 clang 0x00000000008a298c clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 1996 23 clang 0x00000000008c5307 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 535 24 clang 0x00000000008c8c15 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 693 25 clang 0x00000000008a8079 clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::CXX0XAttributeList) + 409 26 clang 0x000000000089cb33 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 1091 27 clang 0x000000000089cd72 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 114 28 clang 0x00000000008854fb clang::ParseAST(clang::Sema&, bool) + 139 29 clang 0x000000000075b444 clang::CodeGenAction::ExecuteAction() + 68 30 clang 0x0000000000661165 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 31 clang 0x0000000000640c5c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 32 clang 0x0000000000638c1e cc1_main(char const**, char const**, char const*, void*) + 622 33 clang 0x000000000063f777 main + 4087 34 libc.so.6 0x00007f0e445eac4d __libc_start_main + 253 35 clang 0x0000000000637409 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 143 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ejotv4.s -x c++ t.cc 1. t.cc:4:4: at annotation token 2. t.cc:2:1: parsing struct/union/class body 'def_helper' 3. t.cc:3:31: parsing function body 'def_maybe_overloads' 4. t.cc:3:31: in compound statement ('{}') clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 10:33:11 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 10:33:11 -0500 (CDT) Subject: [LLVMbugs] [Bug 7623] 'Invalid accessor called' generated by 'template<>template<>a; ' In-Reply-To: References: Message-ID: <20101014153311.A254E2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7623 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Christopher Jefferson 2010-10-14 10:33:10 CDT --- Fixed by trunk 116475. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 10:34:47 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 10:34:47 -0500 (CDT) Subject: [LLVMbugs] [Bug 7684] "Cannot get layout of forward declarations" on invalid code In-Reply-To: References: Message-ID: <20101014153447.6A5B12A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7684 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 10:37:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 10:37:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 7073] Assertion failed: (!EnteredScope && "Already entered the scope!") In-Reply-To: References: Message-ID: <20101014153723.1286B2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7073 Christopher Jefferson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Christopher Jefferson 2010-10-14 10:37:22 CDT --- Fixed as of r116475 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 10:52:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 10:52:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 8378] New: Cannot Build llvm-gcc-4.2-2.8 on Solaris/x86 Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8378 Summary: Cannot Build llvm-gcc-4.2-2.8 on Solaris/x86 Product: tools Version: 2.8 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P Component: llvm-gcc AssignedTo: unassignedbugs at nondot.org ReportedBy: spear at cse.lehigh.edu CC: llvmbugs at cs.uiuc.edu I am unable to build llvm-gcc-4.2-2.8 on Solaris/x86. I successfully built llvm-gcc-4.2-2.7 and llvm-2.7 on Solaris/x86. I can also build llvm-2.8 itself on Solaris/x86. The break occurs only when moving from the released llvm-gcc-4.2-2.7 to llvm-gcc-4.2-2.8 Platform: uname -a == SunOS 5.10 Generic_142901-12 i86pc i386 i86pc Toolchain: gcc 4.5.1 binutils 2.20.1 Configure invocation: ../llvm-gcc-4.2-2.8.source/configure --prefix=/proj/spear0/dtmc_x86/llvm-2.8-gcc --program-prefix=llvm- --enable-llvm=/proj/spear0/dtmc_x86/llvm --enable-languages=c,c++ --enable-checking --with-gnu-as --with-as=/proj/spear0/binutils-2.20.1/bin/as --with-gnu-ld --with-ld=/proj/spear0/binutils-2.20.1/bin/ld The specific error occurs when building libgcc2.c. I'm building using 'gmake' (no -j flag). /tmp/mfs/2.8/build/./gcc/xgcc -B/tmp/mfs/2.8/build/./gcc/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/bin/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/lib/ -isystem /proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/include -isystem /proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../llvm-gcc-4.2-2.8.source/gcc -I../../llvm-gcc-4.2-2.8.source/gcc/. -I../../llvm-gcc-4.2-2.8.source/gcc/../include -I./../intl -I../../llvm-gcc-4.2-2.8.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.8.source/gcc/../libdecnumber -I../libdecnumber -I/proj/spear0/dtmc_x86/llvm/include -DL_mulxc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../llvm-gcc-4.2-2.8.source/gcc/libgcc2.c -o libgcc/./_mulxc3.o ../../llvm-gcc-4.2-2.8.source/gcc/libgcc2.c: In function '__mulxc3': ../../llvm-gcc-4.2-2.8.source/gcc/libgcc2.c:1855: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Re-running gmake reproduces the error, and provides the following background about gcc build progress: [ -f stage_final ] || echo stage3 > stage_final gmake[1]: Entering directory `/tmp/mfs/2.8/build' gmake[2]: Entering directory `/tmp/mfs/2.8/build' gmake[3]: Entering directory `/tmp/mfs/2.8/build' rm -f stage_current gmake[3]: Leaving directory `/tmp/mfs/2.8/build' gmake[2]: Leaving directory `/tmp/mfs/2.8/build' gmake[2]: Entering directory `/tmp/mfs/2.8/build' gmake[3]: Entering directory `/tmp/mfs/2.8/build/libiberty' gmake[4]: Entering directory `/tmp/mfs/2.8/build/libiberty/testsuite' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/tmp/mfs/2.8/build/libiberty/testsuite' gmake[3]: Leaving directory `/tmp/mfs/2.8/build/libiberty' gmake[3]: Entering directory `/tmp/mfs/2.8/build/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) gmake[3]: Leaving directory `/tmp/mfs/2.8/build/intl' gmake[3]: Entering directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty' gmake[4]: Entering directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty/testsuite' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty/testsuite' gmake[3]: Leaving directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty' gmake[3]: Entering directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/fixincludes' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/fixincludes' gmake[3]: Entering directory `/tmp/mfs/2.8/build/libcpp' test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) gmake[3]: Leaving directory `/tmp/mfs/2.8/build/libcpp' gmake[3]: Entering directory `/tmp/mfs/2.8/build/libdecnumber' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/tmp/mfs/2.8/build/libdecnumber' gmake[3]: Entering directory `/tmp/mfs/2.8/build/gcc' gmake[3]: Leaving directory `/tmp/mfs/2.8/build/gcc' gmake[2]: Leaving directory `/tmp/mfs/2.8/build' gmake[2]: Entering directory `/tmp/mfs/2.8/build' gmake[3]: Entering directory `/tmp/mfs/2.8/build' rm -f stage_current gmake[3]: Leaving directory `/tmp/mfs/2.8/build' gmake[2]: Leaving directory `/tmp/mfs/2.8/build' gmake[2]: Entering directory `/tmp/mfs/2.8/build' gmake[3]: Entering directory `/tmp/mfs/2.8/build/libiberty' gmake[4]: Entering directory `/tmp/mfs/2.8/build/libiberty/testsuite' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/tmp/mfs/2.8/build/libiberty/testsuite' gmake[3]: Leaving directory `/tmp/mfs/2.8/build/libiberty' gmake[3]: Entering directory `/tmp/mfs/2.8/build/intl' rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) gmake[3]: Leaving directory `/tmp/mfs/2.8/build/intl' gmake[3]: Entering directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty' gmake[4]: Entering directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty/testsuite' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty/testsuite' gmake[3]: Leaving directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/libiberty' gmake[3]: Entering directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/fixincludes' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/tmp/mfs/2.8/build/build-i386-pc-solaris2.10/fixincludes' gmake[3]: Entering directory `/tmp/mfs/2.8/build/libcpp' test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) gmake[3]: Leaving directory `/tmp/mfs/2.8/build/libcpp' gmake[3]: Entering directory `/tmp/mfs/2.8/build/libdecnumber' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/tmp/mfs/2.8/build/libdecnumber' gmake[3]: Entering directory `/tmp/mfs/2.8/build/gcc' gmake \ CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common " \ CONFIG_H="config.h auto-host.h ../../llvm-gcc-4.2-2.8.source/gcc/../include/ansidecl.h" \ MAKEOVERRIDES= \ -f libgcc.mk all gmake[4]: Entering directory `/tmp/mfs/2.8/build/gcc' gmake GCC_FOR_TARGET="/tmp/mfs/2.8/build/./gcc/xgcc -B/tmp/mfs/2.8/build/./gcc/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/bin/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/lib/ -isystem /proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/include -isystem /proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/sys-include " \ AR_FOR_TARGET="/usr/ccs/bin/ar" \ AR_CREATE_FOR_TARGET="/usr/ccs/bin/ar rc" \ AR_EXTRACT_FOR_TARGET="/usr/ccs/bin/ar x" \ AR_FLAGS_FOR_TARGET="" \ CC="/tmp/mfs/2.8/build/./prev-gcc/xgcc -B/tmp/mfs/2.8/build/./prev-gcc/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/bin/" CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common " \ BUILD_PREFIX="" \ BUILD_PREFIX_1="" \ LANGUAGES="" \ LIBGCC2_CFLAGS="-O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED " \ LIBGCC2_STATIC_CFLAGS="" \ MULTILIB_CFLAGS="" T= gmon.o crtbegin.o crtend.o gmake[5]: Entering directory `/tmp/mfs/2.8/build/gcc' gmake[5]: `crtend.o' is up to date. gmake[5]: Leaving directory `/tmp/mfs/2.8/build/gcc' /tmp/mfs/2.8/build/./gcc/xgcc -B/tmp/mfs/2.8/build/./gcc/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/bin/ -B/proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/lib/ -isystem /proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/include -isystem /proj/spear0/dtmc_x86/llvm-2.8-gcc/i386-pc-solaris2.10/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../llvm-gcc-4.2-2.8.source/gcc -I../../llvm-gcc-4.2-2.8.source/gcc/. -I../../llvm-gcc-4.2-2.8.source/gcc/../include -I./../intl -I../../llvm-gcc-4.2-2.8.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.8.source/gcc/../libdecnumber -I../libdecnumber -I/proj/spear0/dtmc_x86/llvm/include -DL_mulxc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../llvm-gcc-4.2-2.8.source/gcc/libgcc2.c -o libgcc/./_mulxc3.o ../../llvm-gcc-4.2-2.8.source/gcc/libgcc2.c: In function '__mulxc3': ../../llvm-gcc-4.2-2.8.source/gcc/libgcc2.c:1855: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[4]: *** [libgcc/./_mulxc3.o] Error 1 gmake[4]: Leaving directory `/tmp/mfs/2.8/build/gcc' gmake[3]: *** [stmp-multilib] Error 2 gmake[3]: Leaving directory `/tmp/mfs/2.8/build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/mfs/2.8/build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/mfs/2.8/build' gmake: *** [all] Error 2 The bug also occurs when using gcc 4.4.1 on Solaris/x86. And even though the exact error is "internal compiler error", which would imply a gcc bug, the fact that both compilers can handle llvm-gcc-2.7-4.2 but not llvm-gcc-2.8-4.2 suggests that this has more to do with changes to llvm-gcc between the 2.7 and 2.8 releases. Any advice would be greatly appreciated! - Mike Spear -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 10:55:44 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 10:55:44 -0500 (CDT) Subject: [LLVMbugs] [Bug 8375] Symbol is undefined when LLVM built by CMake In-Reply-To: References: Message-ID: <20101014155544.C74652A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8375 ?scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ofv at wanadoo.es Resolution| |FIXED --- Comment #1 from ?scar Fuentes 2010-10-14 10:55:44 CDT --- A generic fix was implemented by r116479 -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 13:07:58 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 13:07:58 -0500 (CDT) Subject: [LLVMbugs] [Bug 8374] Generalize clang blocks to support other closure-like language features In-Reply-To: References: Message-ID: <20101014180759.04CFF2A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8374 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Douglas Gregor 2010-10-14 13:07:58 CDT --- While I agree with the basic idea (and several of the specifics here) of generalizing blocks to support other kinds of closures, this isn't the kind of thing we keep in our bug system. When someone starts implementing these other features, they'll probably start by refactoring the existing code. As Chris says, it's not actionable, so I'm going to close the bug itself. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 13:09:42 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 13:09:42 -0500 (CDT) Subject: [LLVMbugs] [Bug 8379] New: Use of llvm.powi.f64 on Windows crashes Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8379 Summary: Use of llvm.powi.f64 on Windows crashes Product: new-bugs Version: 2.8 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: mtsmith at synopsys.com CC: llvmbugs at cs.uiuc.edu The attached file demonstrates the problem. Run llvm-as on it, then run it using lli, and it crashes. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 14:04:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 14:04:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8380] New: Assertion `StartColNo <= EndColNo && "Invalid range!"' on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8380 Summary: Assertion `StartColNo <= EndColNo && "Invalid range!"' on invalid code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The code snippet: extern""a{ Leads to the following backtrack: clang++ *15231.cc t.bashed.15231.cc:1:7: error: unknown linkage language extern""a{ ^ t.bashed.15231.cc:1:9: error: C++ requires a type specifier for all declarations clang: TextDiagnosticPrinter.cpp:124: void clang::TextDiagnosticPrinter::HighlightRange(const clang::CharSourceRange&, const clang::SourceManager&, unsigned int, clang::FileID, std::string&, const std::string&): Assertion `StartColNo <= EndColNo && "Invalid range!"' failed. 0 clang 0x000000000165139f 1 clang 0x0000000001653612 2 libpthread.so.0 0x00007ff2e138e8f0 3 libc.so.6 0x00007ff2e067da75 gsignal + 53 4 libc.so.6 0x00007ff2e06815c0 abort + 384 5 libc.so.6 0x00007ff2e0676941 __assert_fail + 241 6 clang 0x0000000000681a33 clang::TextDiagnosticPrinter::HighlightRange(clang::CharSourceRange const&, clang::SourceManager const&, unsigned int, clang::FileID, std::string&, std::string const&) + 1331 7 clang 0x0000000000682bd8 clang::TextDiagnosticPrinter::EmitCaretDiagnostic(clang::SourceLocation, clang::CharSourceRange*, unsigned int, clang::SourceManager const&, clang::FixItHint const*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) + 3912 8 clang 0x000000000068487d clang::TextDiagnosticPrinter::HandleDiagnostic(clang::Diagnostic::Level, clang::DiagnosticInfo const&) + 3997 9 clang 0x0000000000cf7dbb clang::Diagnostic::ProcessDiag() + 523 10 clang 0x0000000000cf7f4d clang::DiagnosticBuilder::Emit() + 29 11 clang 0x00000000008d6c2d clang::Sema::SemaDiagnosticBuilder::~SemaDiagnosticBuilder() + 173 12 clang 0x0000000000aa6b25 13 clang 0x0000000000aa8442 clang::Sema::GetTypeForDeclarator(clang::Declarator&, clang::Scope*, clang::TagDecl**) + 130 14 clang 0x0000000000945d6d clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, clang::ASTMultiPtr, bool) + 717 15 clang 0x00000000008a04cb clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&) + 107 16 clang 0x00000000008a71f1 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*) + 609 17 clang 0x000000000089a8c9 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 201 18 clang 0x000000000089c74f clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 95 19 clang 0x00000000008b0a88 clang::Parser::ParseLinkage(clang::Parser::ParsingDeclSpec&, unsigned int) + 488 20 clang 0x000000000089a9c8 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 456 21 clang 0x000000000089ace4 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 372 22 clang 0x000000000089cc25 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 1333 23 clang 0x000000000089cd72 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 114 24 clang 0x00000000008854fb clang::ParseAST(clang::Sema&, bool) + 139 25 clang 0x000000000075b444 clang::CodeGenAction::ExecuteAction() + 68 26 clang 0x0000000000661165 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 27 clang 0x0000000000640c5c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 28 clang 0x0000000000638c1e cc1_main(char const**, char const**, char const*, void*) + 622 29 clang 0x000000000063f777 main + 4087 30 libc.so.6 0x00007ff2e0668c4d __libc_start_main + 253 31 clang 0x0000000000637409 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.bashed.15231.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 80 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-tbcQ8h.s -x c++ t.bashed.15231.cc 1. t.bashed.15231.cc:1:10: current parser token '{' clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 17:47:53 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 17:47:53 -0500 (CDT) Subject: [LLVMbugs] [Bug 8381] New: Incorrect x86/SSE code generation involving <<8 x i16>> vector Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8381 Summary: Incorrect x86/SSE code generation involving <<8 x i16>> vector Product: new-bugs Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: brian.e.paul at gmail.com CC: llvmbugs at cs.uiuc.edu Created an attachment (id=5618) --> (http://llvm.org/bugs/attachment.cgi?id=5618) bytecode which generates incorrect code We found this issue with the Mesa/Gallium LLVMpipe driver. At one point we're constructing a <<8 x i16>> vector. All elements should have the same value. The value comes from a scalar floating point calculation. The float is converted to i32 and that's trunc'd to i16 before we build the vector. This worked with LLVM 2.7 but fails with LLVM 2.8. We can work around the bug by inserting a special no-op shuffle which replicates the [0] and [2] elements to the other elements in the vector. This shouldn't be necessary, of course. I'm attaching the defective bytecode file and a bytecode file with our work-around. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 18:08:51 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 18:08:51 -0500 (CDT) Subject: [LLVMbugs] [Bug 8382] New: wrong diagnostic on missing template arguments Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8382 Summary: wrong diagnostic on missing template arguments Product: clang Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: nlewycky at google.com CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com Consider this testcase: template class Foo {}; class Bar : public Foo {}; the diagnostic clang produces is: b2973185.cc:3:20: error: expected class name class Bar : public Foo {}; ^ 1 error generated. which isn't quite right; Foo is a class name, so what's wrong here? It's that Foo is a template and I didn't specify the template arguments. It'd be great if clang pointed that out. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 18:42:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 18:42:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 8383] New: #pragma weak does not honor visibility Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8383 Summary: #pragma weak does not honor visibility Product: clang Version: 2.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs AssignedTo: unassignedclangbugs at nondot.org ReportedBy: jed at 59a2.org CC: llvmbugs at cs.uiuc.edu $ cat weak.c #define EXPORT __attribute((visibility("default"))) extern int EXPORT foo_a(void); extern int EXPORT foo_b(void); extern int EXPORT foo_c(void); #pragma weak foo_a = foo_c int foo_b(void) __attribute((weak, alias(("foo_c")))); int foo_c(void) { return 0; } $ clang -shared -fvisibility=hidden weak.c -o libweak.so && nm -D libweak.so | grep foo 0000000000000550 W foo_b 0000000000000550 T foo_c $ gcc -shared -fvisibility=hidden weak.c -o libweak.so && nm -D libweak.so | grep foo 000000000000055c W foo_a 000000000000055c W foo_b 000000000000055c T foo_c The visibility of the symbol "foo_a" is not respected, but the pragma is clearly supported because the following works as expected. $ clang -shared -fvisibility=default weak.c -o libweak.so && nm -D libweak.so | grep foo 0000000000000580 W foo_a 0000000000000580 W foo_b 0000000000000580 T foo_c $ clang --version clang version 2.8 (branches/release_28) Target: x86_64-unknown-linux-gnu Thread model: posix $ uname -a Linux kunyang 2.6.35-ARCH #1 SMP PREEMPT Wed Sep 29 08:45:18 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 19:53:02 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 19:53:02 -0500 (CDT) Subject: [LLVMbugs] [Bug 8344] Scoped over.built OO_Conditional enum fix In-Reply-To: References: Message-ID: <20101015005302.C8E292A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8344 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-10-14 19:53:02 CDT --- Committed in r116549, thanks! -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 19:56:19 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 19:56:19 -0500 (CDT) Subject: [LLVMbugs] [Bug 8155] couldn't get a simple c++ code to compile In-Reply-To: References: Message-ID: <20101015005619.9F70E2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8155 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #8 from Douglas Gregor 2010-10-14 19:56:18 CDT --- Closing this bug, since we can't reproduce the problem. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 20:06:15 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 20:06:15 -0500 (CDT) Subject: [LLVMbugs] [Bug 6920] clang++: doesn't emit inline operator delete from parent class In-Reply-To: References: Message-ID: <20101015010615.2ABAF2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6920 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-14 20:06:14 CDT --- This is working with top-of-tree Clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 20:07:22 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 20:07:22 -0500 (CDT) Subject: [LLVMbugs] [Bug 7038] ast-dump crash for inline-declared structs in other structs In-Reply-To: References: Message-ID: <20101015010722.3F94B2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7038 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-14 20:07:21 CDT --- This is working fine with top-of-tree Clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 20:16:28 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 20:16:28 -0500 (CDT) Subject: [LLVMbugs] [Bug 7053] clang++ accepts invalid template code In-Reply-To: References: Message-ID: <20101015011628.984902A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7053 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-14 20:16:28 CDT --- Fixed in Clang r116551. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 20:22:10 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 20:22:10 -0500 (CDT) Subject: [LLVMbugs] [Bug 7076] extern "C" handled like "extern" In-Reply-To: References: Message-ID: <20101015012210.5AE052A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7076 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Douglas Gregor 2010-10-14 20:22:09 CDT --- Fixed in Clang r116553. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 20:31:14 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 20:31:14 -0500 (CDT) Subject: [LLVMbugs] [Bug 8364] Verifier doesn't flag out-of-module constants, BC writing crashes In-Reply-To: References: Message-ID: <20101015013114.7AE4F2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8364 Bill Wendling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |wendling at apple.com Resolution| |INVALID --- Comment #1 from Bill Wendling 2010-10-14 20:31:13 CDT --- You probably want to use the Module::getOrInsertFunction and Module::getOrInsertGlobal methods instead of manually putting them into the Module's lists. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 20:57:40 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 20:57:40 -0500 (CDT) Subject: [LLVMbugs] [Bug 4418] JIT broken on MingW for available_externally functions. In-Reply-To: References: Message-ID: <20101015015740.398422A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=4418 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from NAKAMURA Takumi 2010-10-14 20:57:39 CDT --- Now it works with both llvm-gcc and clang on mingw. It seems fixed in r85077. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 21:02:05 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 21:02:05 -0500 (CDT) Subject: [LLVMbugs] [Bug 6275] Clang doesn't codegen calls to dllimport functions properly In-Reply-To: References: Message-ID: <20101015020206.1B8B72A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6275 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from NAKAMURA Takumi 2010-10-14 21:02:05 CDT --- Fixed in r116184. Now we can see "declare dllimport void @foo(i32)" and "calll *__imp__foo" with clang. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 21:07:12 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 21:07:12 -0500 (CDT) Subject: [LLVMbugs] [Bug 6269] Clang doesn't support declspec attributes In-Reply-To: References: Message-ID: <20101015020712.5D40F2A6C124@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6269 NAKAMURA Takumi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #9 from NAKAMURA Takumi 2010-10-14 21:07:11 CDT --- (In reply to comment #8) > - Clang doesn't support declspec attributes It seems fixed :p > - Clang doesn't codegen calls to dllimport functions properly Fixed in r116184. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Thu Oct 14 21:51:30 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Thu, 14 Oct 2010 21:51:30 -0500 (CDT) Subject: [LLVMbugs] [Bug 6269] Clang doesn't support declspec attributes In-Reply-To: References: Message-ID: <20101015025130.BB3E32A6C12D@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6269 Charles Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #10 from Charles Davis 2010-10-14 21:51:30 CDT --- (In reply to comment #9) > (In reply to comment #8) > > - Clang doesn't support declspec attributes > > It seems fixed :p Yes, Clang supports *some* declspec attributes, but not all of them, or even a significant portion of them, for that matter. In fact, the only ones handled are dllimport and dllexport. Reopening. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 00:10:48 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 00:10:48 -0500 (CDT) Subject: [LLVMbugs] [Bug 6275] Clang doesn't codegen calls to dllimport functions properly In-Reply-To: References: Message-ID: <20101015051049.026602A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=6275 Eli Friedman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #4 from Eli Friedman 2010-10-15 00:10:48 CDT --- Err, for what definition of "working"? Testcase is still broken for me. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 03:29:08 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 03:29:08 -0500 (CDT) Subject: [LLVMbugs] [Bug 8371] __attribute__ ((__const)) not recognized In-Reply-To: References: Message-ID: <20101015082908.2C18D2A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8371 Gabor Greif changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Gabor Greif 2010-10-15 03:29:07 CDT --- fixed by r116570. Contains a comment. The fix is so simple, that a test for it is (IMHO) not needed, anyway our app tests it well, so I'll notice when somebody breaks it :-) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 05:23:29 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 05:23:29 -0500 (CDT) Subject: [LLVMbugs] [Bug 8384] New: Assertion `Access == AS_private || Access == AS_protected' on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8384 Summary: Assertion `Access == AS_private || Access == AS_protected' on invalid code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The code: struct{template::EffectiveContext&, const clang::CXXRecordDecl*, clang::AccessSpecifier, const::AccessTarget&): Assertion `Access == AS_private || Access == AS_protected' failed. 0 clang 0x000000000165139f 1 clang 0x0000000001653612 2 libpthread.so.0 0x00007fe6532c98f0 3 libc.so.6 0x00007fe6525b8a75 gsignal + 53 4 libc.so.6 0x00007fe6525bc5c0 abort + 384 5 libc.so.6 0x00007fe6525b1941 __assert_fail + 241 6 clang 0x00000000008dd651 7 clang 0x00000000008ddc46 8 clang 0x00000000008de4b2 9 clang 0x00000000008deef1 10 clang 0x00000000008df3ba clang::Sema::CheckLookupAccess(clang::LookupResult const&) + 330 11 clang 0x000000000092cbb5 clang::Sema::getTypeName(clang::IdentifierInfo&, clang::SourceLocation, clang::Scope*, clang::CXXScopeSpec*, bool, clang::OpaquePtr) + 1013 12 clang 0x00000000008a2f13 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 3411 13 clang 0x00000000008c5f11 clang::Parser::ParseNonTypeTemplateParameter(unsigned int, unsigned int) + 497 14 clang 0x00000000008c85e7 clang::Parser::ParseTemplateParameterList(unsigned int, llvm::SmallVectorImpl&) + 55 15 clang 0x00000000008c887c clang::Parser::ParseTemplateParameters(unsigned int, llvm::SmallVectorImpl&, clang::SourceLocation&, clang::SourceLocation&) + 284 16 clang 0x00000000008c8afa clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier) + 410 17 clang 0x00000000008afa2f clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject*) + 2399 18 clang 0x00000000008b1c0f clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 1599 19 clang 0x00000000008b2ad0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 2800 20 clang 0x00000000008a298c clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 1996 21 clang 0x000000000089a896 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 150 22 clang 0x000000000089ace4 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 372 23 clang 0x000000000089cc25 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 1333 24 clang 0x000000000089cd72 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 114 25 clang 0x00000000008854fb clang::ParseAST(clang::Sema&, bool) + 139 26 clang 0x000000000075b444 clang::CodeGenAction::ExecuteAction() + 68 27 clang 0x0000000000661165 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 28 clang 0x0000000000640c5c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 29 clang 0x0000000000638c1e cc1_main(char const**, char const**, char const*, void*) + 622 30 clang 0x000000000063f777 main + 4087 31 libc.so.6 0x00007fe6525a3c4d __libc_start_main + 253 32 clang 0x0000000000637409 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.bashed.27877.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 171 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-X5OKLG.s -x c++ t.bashed.27877.cc 1. t.bashed.27877.cc:1:37: current parser token 'aa' 2. t.bashed.27877.cc:1:1: parsing struct/union/class body clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 05:27:06 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 05:27:06 -0500 (CDT) Subject: [LLVMbugs] [Bug 8385] New: Assertion `Access != AS_none && "Access specifier is AS_none inside a record decl"' on invalid code Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8385 Summary: Assertion `Access != AS_none && "Access specifier is AS_none inside a record decl"' on invalid code Product: clang Version: trunk Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P Component: C++ AssignedTo: unassignedclangbugs at nondot.org ReportedBy: chris at bubblescope.net CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com The code: struct{template struct{ Produces the backtrack: clang: DeclBase.cpp:443: void clang::Decl::CheckAccessDeclContext() const: Assertion `Access != AS_none && "Access specifier is AS_none inside a record decl"' failed. 0 clang 0x000000000165139f 1 clang 0x0000000001653612 2 libpthread.so.0 0x00007f9d331168f0 3 libc.so.6 0x00007f9d32405a75 gsignal + 53 4 libc.so.6 0x00007f9d324095c0 abort + 384 5 libc.so.6 0x00007f9d323fe941 __assert_fail + 241 6 clang 0x0000000000c43d49 clang::Decl::CheckAccessDeclContext() const + 121 7 clang 0x0000000000938436 clang::Sema::BuildAnonymousStructOrUnion(clang::Scope*, clang::DeclSpec&, clang::AccessSpecifier, clang::RecordDecl*) + 886 8 clang 0x0000000000939221 clang::Sema::ParsedFreeStandingDeclSpec(clang::Scope*, clang::AccessSpecifier, clang::DeclSpec&) + 721 9 clang 0x00000000008c5901 clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier) + 2065 10 clang 0x00000000008c5cd7 clang::Parser::ParseExplicitInstantiation(clang::SourceLocation, clang::SourceLocation, clang::SourceLocation&) + 119 11 clang 0x00000000008afa2f clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ParsingDeclRAIIObject*) + 2399 12 clang 0x00000000008b1c0f clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int, clang::Decl*) + 1599 13 clang 0x00000000008b2ad0 clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool) + 2800 14 clang 0x00000000008a298c clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext) + 1996 15 clang 0x000000000089a896 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AttributeList*, clang::AccessSpecifier) + 150 16 clang 0x000000000089ace4 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*, clang::AccessSpecifier) + 372 17 clang 0x000000000089cc25 clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList, clang::Parser::ParsingDeclSpec*) + 1333 18 clang 0x000000000089cd72 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 114 19 clang 0x00000000008854fb clang::ParseAST(clang::Sema&, bool) + 139 20 clang 0x000000000075b444 clang::CodeGenAction::ExecuteAction() + 68 21 clang 0x0000000000661165 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357 22 clang 0x0000000000640c5c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276 23 clang 0x0000000000638c1e cc1_main(char const**, char const**, char const*, void*) + 622 24 clang 0x000000000063f777 main + 4087 25 libc.so.6 0x00007f9d323f0c4d __libc_start_main + 253 26 clang 0x0000000000637409 Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name t.bashed.16288.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1 -resource-dir /usr/local/lib/clang/2.9 -ferror-limit 19 -fmessage-length 171 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-nWJ8j3.s -x c++ t.bashed.16288.cc 1. parser at end of file 2. t.bashed.16288.cc:1:1: parsing struct/union/class body clang: error: clang frontend command failed due to signal 6 (use -v to see invocation) -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 08:22:50 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 08:22:50 -0500 (CDT) Subject: [LLVMbugs] [Bug 7082] No warning/error for matching class and member variable/function names. In-Reply-To: References: Message-ID: <20101015132250.2958A2A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=7082 Douglas Gregor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Douglas Gregor 2010-10-15 08:22:49 CDT --- Fixed in Clang r116573. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 08:33:27 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 08:33:27 -0500 (CDT) Subject: [LLVMbugs] [Bug 8364] Verifier doesn't flag out-of-module constants, BC writing crashes In-Reply-To: References: Message-ID: <20101015133327.28DA72A6C12E@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8364 Duncan Sands changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #4 from Duncan Sands 2010-10-15 08:33:26 CDT --- I don't see how this can be considered resolved, since the verifier hasn't been beefed up as requested. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 08:36:04 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 08:36:04 -0500 (CDT) Subject: [LLVMbugs] [Bug 8386] New: template default parameter type of function default argument causes missing symbol Message-ID: http://llvm.org/bugs/show_bug.cgi?id=8386 Summary: template default parameter type of function default argument causes missing symbol Product: new-bugs Version: trunk Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs AssignedTo: unassignedbugs at nondot.org ReportedBy: Axel.Naumann at cern.ch CC: llvmbugs at cs.uiuc.edu $ cat t.cxx #include void Invoke(const std::vector& = std::vector()); void f() { Invoke(); } $ clang++ -O2 -c t.cxx && nm t.o | grep __ZNSaIPvEC1Ev U __ZNSaIPvEC1Ev whereas e.g.: $ g++ -O2 -c t.cxx && nm t.o | grep __ZNSaIPvEC1Ev I'm pretty sure that g++ is correct here. This behavior of clang++ results in an undefined symbol __ZNSaIPvEC1Ev when loading the library containing t.o. Cheers, Axel. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at llvm.org Fri Oct 15 09:57:23 2010 From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org) Date: Fri, 15 Oct 2010 09:57:23 -0500 (CDT) Subject: [LLVMbugs] [Bug 8381] Incorrect x86/SSE code generation involving <<8 x i16>> vector In-Reply-To: References: Message-ID: <20101015145724.44E312A6C12C@llvm.org> http://llvm.org/bugs/show_bug.cgi?id=8381 Duncan Sands