[llvm-bugs] [Bug 26825] Clang faults generating coverage for macro expansion
https://llvm.org/bugs/show_bug.cgi?id=26825 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Vedant Kumar --- Fixed in clang r262697. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26836] New: [ms] type conversion with a type named with two words cannot be compiled in if statement
https://llvm.org/bugs/show_bug.cgi?id=26836
Bug ID: 26836
Summary: [ms] type conversion with a type named with two words
cannot be compiled in if statement
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: andrey.kules...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
!- the way MS compiler works is logical and explainable, because such behavior
is user friendly.
clang can compile such line:
"if( long(t1) < t2 ) ;"
a little bit confusing for a user that this line cannot be compiled:
"if( unsigned long(t1) < t2 ) ;"
I suppose that this feature might be added to clang under fms-compability
option -!
=Environment
Language: c++
OS: Windows
Version: trunk
=How to reproduce
void f(int t1, unsigned long t2 )
{
if( unsigned long(t1) < t2 ) ;
}
=Error===
>>> clang:
error: variable declaration in condition must have an initializer
if( unsigned long(t1) < t2 ) ;
error: expected ')'
if( unsigned long(t1) < t2 ) ;
>>> MSVC/intel icc compiler: no diagnostics
>>> gcc:
error: expected primary-expression before ‘unsigned’
if( unsigned long(t1) < t2 ) ;
error: expected ‘)’ before ‘unsigned’
Andrey Kuleshov
==
Software Engineer
Intel Compiler Team
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26837] New: Availability of SSE detrimental to code performance
https://llvm.org/bugs/show_bug.cgi?id=26837 Bug ID: 26837 Summary: Availability of SSE detrimental to code performance Product: libraries Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: tulip...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The following Rust playpen snippet (possible to see IR or ASM interactively) http://is.gd/FrGoDm produces the following benchmark results, depending on codegen options: Pentium2 test folds1 ... bench: 736 ns/iter (+/- 5) test folds2 ... bench: 731 ns/iter (+/- 1) Pentium3 (or +sse) test folds1 ... bench: 932 ns/iter (+/- 2) test folds2 ... bench: 933 ns/iter (+/- 8) Pentium4 (or +sse2) running 2 tests test folds1 ... bench: 249 ns/iter (+/- 1) test folds2 ... bench: 733 ns/iter (+/- 6) It seems availability of SSE2 enables successful vectorisation, whereas of SSE makes the code slower. The latter shouldn't happen. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26814] lld needs to set DF_TEXTREL if the output contains relocations in non-writable segments
https://llvm.org/bugs/show_bug.cgi?id=26814 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER --- Comment #3 from Rafael Ávila de Espíndola --- closing per comment 2 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 26814, which changed state. Bug 26814 Summary: lld needs to set DF_TEXTREL if the output contains relocations in non-writable segments https://llvm.org/bugs/show_bug.cgi?id=26814 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26838] New: clang option -mabi (and -cc1 -meabi) has no effect when cross-compiling to ARM
https://llvm.org/bugs/show_bug.cgi?id=26838 Bug ID: 26838 Summary: clang option -mabi (and -cc1 -meabi) has no effect when cross-compiling to ARM Product: clang Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: david.cab+llvm...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified It is impossible to compile an arm binary with an EABI other than EABI 5. Steps to reproduce: touch main.c clang -target arm---elf -mabi=apcs-gnu -msoft-float -c main.c Other options include: clang -cc1 -triple arm -meabi gnu -target-abi apcs-gnu -emit-obj main.c clang -cc1 -triple arm -meabi gnu -emit-obj main.c clang -cc1 -triple arm -meabi 4 -emit-obj main.c Actual Results: An EABI5 object is created. "file main.o" results in main.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped Expected Results: An object file with the appropriate EABI (other than 5) should have been generated. Build Date & Platform: Tested with Clang 3.7.1 and Clang 3.8.0-rc3 precompiled binaries for Ubuntu 15.10 x86_64 available at llvm.org. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26839] New: Clang -cc1 crashes if an unknown -target-cpu is passed for -triple arm
https://llvm.org/bugs/show_bug.cgi?id=26839 Bug ID: 26839 Summary: Clang -cc1 crashes if an unknown -target-cpu is passed for -triple arm Product: clang Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: david.cab+llvm...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Steps to Reproduce: touch main.c clang -cc1 -triple arm -target-cpu xyz main.c -emit-obj Actual Results: The application crashed. $ ./clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang -cc1 -triple arm -target-cpu xyz main.c -emit-obj #0 0x01594268 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x1594268) #1 0x015948e7 SignalHandler(int) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x15948e7) #2 0x7f8c41763d10 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d10) #3 0x7f8c40a3c8f0 /build/glibc-ryFjv0/glibc-2.21/string/../sysdeps/x86_64/multiarch/memcmp-sse4.S:878:0 #4 0x0156bff2 llvm::ARM::getCanonicalArchName(llvm::StringRef) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x156bff2) #5 0x0156cc76 llvm::ARM::parseArchProfile(llvm::StringRef) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x156cc76) #6 0x02965a77 (anonymous namespace)::ARMTargetInfo::setArchInfo(unsigned int) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x2965a77) #7 0x02962973 (anonymous namespace)::ARMTargetInfo::setCPU(std::__cxx11::basic_string, std::allocator > const&) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x2962973) #8 0x02957183 clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&, std::shared_ptr const&) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x2957183) #9 0x0193056d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x193056d) #10 0x019d9b0f clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x19d9b0f) #11 0x00742b9d cc1_main(llvm::ArrayRef, char const*, void*) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x742b9d) #12 0x00741ed1 main (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x741ed1) #13 0x7f8c408eea40 __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:323:0 #14 0x0073eeb9 _start (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x73eeb9) Stack dump: 0.Program arguments: ./clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang -cc1 -triple arm -target-cpu xyz main.c -emit-obj Segmentation fault (core dumped) Expected results: No crash and print an error message. Build Date & Platform: Clang 3.8.0-rc3 prebuilt binaries for Ubuntu 15.10 available at llvm.org. Additional Information: This is a regression with respect to clang 3.7.1. Using clang 3.7.1 results in normal behaviour. $ ./clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/clang -cc1 -triple arm -target-cpu xyz main.c -emit-obj 'xyz' is not a recognized processor for this target (ignoring processor) [repeats 13 times] $ ./clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-15.10/bin/clang -cc1 -target-cpu xyz main.c -emit-obj error: unknown target CPU 'xyz' With clang 3.8.0-rc3 the results are expected for x86-64 but a crash for -triple arm. $ ./clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang -cc1 -target-cpu xyz main.c -emit-obj error: unknown target CPU 'xyz' $ ./clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang -cc1 -triple arm -target-cpu xyz main.c -emit-obj #0 0x01594268 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/score/clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10/bin/clang-3.8+0x1594268) [...] -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26841] New: [accepts-invalid] Member template inside a local class
https://llvm.org/bugs/show_bug.cgi?id=26841
Bug ID: 26841
Summary: [accepts-invalid] Member template inside a local class
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: ldionn...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code compiles successfully on Clang trunk, but it is invalid
according to the C++14 standard:
int main() {
struct foo { template using nested = void; };
}
The relevant part of the standard is in [temp.mem], §14.5.2/2:
A local class of non-closure type shall not have member templates.
Live example: http://melpon.org/wandbox/permlink/6iFYFG3gcgzOYftp
Surprisingly, this bug is marked as fixed in bug [16947], so I guess this
is a regression.
[16947]: https://llvm.org/bugs/show_bug.cgi?id=16947
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26842] New: LLDB GUI segfault when continuing with the thread frame list expanded
https://llvm.org/bugs/show_bug.cgi?id=26842 Bug ID: 26842 Summary: LLDB GUI segfault when continuing with the thread frame list expanded Product: lldb Version: 3.8 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: kknb1...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15986 --> https://llvm.org/bugs/attachment.cgi?id=15986&action=edit Example backtrace of a crash, plus the proposed patch to fix I have a fix for this, but I wasn't sure if the correct etiquette is to file a bug report before posting a patch to lldb-commits? If the frame stack changes while the list is expanded in the Threads window, there will be a high likelihood of a segfault. For example, expanding the list and then "continue" to another breakpoint where the list is different. I can give a specific program and instructions if required but any program should do it. An example stack trace is attached. This is with the version of lldb shipped with XCode 7.2.1 (lldb-340.4.119.1) as well as the current head (as at 04/Mar/16). The problem is that, when creating the updated list it is done with vector::resize( , ); (via calls to TreeItem::Resize in IOHandler.cpp lines 3312 and 3422). The intention of the code is to fill the m_children vector with copies of , but std::vector::resize only uses the for new values - items already in the vector are left untouched. Hence all items up to the old size will have invalid pointers to parent etcetera, and subsequent Draw calls will screw up. I propose to insert a call to TreeItem::ClearChildren() immediately before the TreeItem::Resize(..) calls so that all children correctly take on the new value. A patch is attached, but I could only append one file so it's after the backtrace. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26843] New: wrong code at -Os and above on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=26843
Bug ID: 26843
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the current clang trunk on
x86_64-linux-gnu at -Os and above in both the 32-bit and 64-bit modes.
This is a regression from 3.7.x.
$ clang-trunk -v
clang version 3.9.0 (trunk 262590)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/tools/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang-trunk -O1 small.c; ./a.out
$ clang-3.7 -Os small.c; ./a.out
$
$ clang-trunk -Os small.c
$ ./a.out
Aborted (core dumped)
$
-
int a, b[4], c;
void
fn1 ()
{
b[1] = 1;
if (a)
for (a = 1; a < 4; a++)
b[a] = 0;
a = 1;
}
int
main ()
{
for (; c < 2; c++)
fn1 ();
if (b[1] != 0)
__builtin_abort ();
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 17006] no email for PR17004 (clang / formatter) and PR16996 (libc++abi)
https://llvm.org/bugs/show_bug.cgi?id=17006 Tanya Lattner changed: What|Removed |Added Status|NEW |RESOLVED CC||to...@nondot.org Resolution|--- |WONTFIX --- Comment #1 from Tanya Lattner --- Closing old bugs. Please file a new bug for any recent issues. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24641] adjustments to the autoconf build system when building on Solaris
https://llvm.org/bugs/show_bug.cgi?id=24641 Tanya Lattner changed: What|Removed |Added Status|NEW |RESOLVED CC||to...@nondot.org Resolution|--- |WONTFIX --- Comment #8 from Tanya Lattner --- autoconf is no longer. Please investigate with Cmake and file appropriate bugs. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25994] trying to register acct w/@gentoo.org fails
https://llvm.org/bugs/show_bug.cgi?id=25994 Mike Frysinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mike Frysinger --- looks like it's been fixed at some point. i can request a new acct & change my existing one. and i've done so now :). -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26844] New: clang 3.8.0/powerpc C++ exception .eh_frame ABI violation/incompleteness leads to SEGV
https://llvm.org/bugs/show_bug.cgi?id=26844 Bug ID: 26844 Summary: clang 3.8.0/powerpc C++ exception .eh_frame ABI violation/incompleteness leads to SEGV Product: clang Version: 3.8 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: mar...@dsl-only.net CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified [This is for FreeBSD's projects/clang380-import-r296011 at the time of submittal.] In the normal C++ ABI exception handling uses 4 scratch registers: "These scratch registers are reserved for passing arguments between the personality routine and the landing pads". This is for "an unwind context representing a handler frame, for which the personality routine will return _URC_INSTALL_CONTEXT" (_Unwind_SetGR). Prior to executing in the landing pad the context record is used to restore various registers "to their state in the frame before the call that threw that exception": callee-saved (not altered by the personality routine) and scratch. For TARGET_ARCH=powerpc (or powerpc64) FreeBSD's system libgcc_s _Unwind_RaiseException gets differing behavior for this between gcc/g++ and clang/clang++ for the scratch registers (and more): A) gcc/g++ uses the 4 registers r3, r4, r5, r6 as the scratch registers and sets up to save/restore them, doing so being reported on by the .eh_frame information for _Unwind_RaiseException. It also sets up to save/restore R14-r31 and floating point registers as r46-r63. It also sets up to save/restore "r70" (holding the value from mfcr). (The powerpc ABI uses a bit in the cr for floating point usage information in the call standard.) B) clang/clang++ does not set up to save/restore any scratch registers or a value from mfcr. It does set up to save/restore r14-r31 and floating point registers as r46-r63. The result is that if things get to the point of the following FreeBSD code as part of handling the exception then the first _Unwind_SetGR gets a SEGV. __builtin_eh_return_data_regno (0) returns 3 to identify r3 as the register context. 678 /* For targets with pointers smaller than the word size, we must extend the 679 pointer, and this extension is target dependent. */ 680 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), 681 __builtin_extend_pointer (ue_header)); 682 _Unwind_SetGR (context, __builtin_eh_return_data_regno (1), 683 handler_switch_value); 684 _Unwind_SetIP (context, landing_pad); As evidence of the difference for scratch register handling (and "r70"/cr handling). . . gcc/g++ dwarfdump -v -v -F output extraction for _Unwind_RaiseException: fde section offset 1104 0x0450 cie offset for fde: 1108 0x0454 0 DW_CFA_advance_loc 8 (8 * 1) 1 DW_CFA_def_cfa_offset 3024 4 DW_CFA_advance_loc1 156 6 DW_CFA_offset r4 -232 (58 * -4) 8 DW_CFA_offset r3 -236 (59 * -4) 10 DW_CFA_offset r28 -160 (40 * -4) 12 DW_CFA_offset r27 -164 (41 * -4) 14 DW_CFA_offset r26 -168 (42 * -4) 16 DW_CFA_offset r25 -172 (43 * -4) 18 DW_CFA_offset r24 -176 (44 * -4) 20 DW_CFA_offset r23 -180 (45 * -4) 22 DW_CFA_offset r22 -184 (46 * -4) 24 DW_CFA_offset r21 -188 (47 * -4) 26 DW_CFA_offset r20 -192 (48 * -4) 28 DW_CFA_offset r19 -196 (49 * -4) 30 DW_CFA_offset r18 -200 (50 * -4) 32 DW_CFA_offset r17 -204 (51 * -4) 34 DW_CFA_offset r16 -208 (52 * -4) 36 DW_CFA_offset r15 -212 (53 * -4) 38 DW_CFA_offset r14 -216 (54 * -4) 40 DW_CFA_offset r63 -8 (2 * -4) 42 DW_CFA_offset r62 -16 (4 * -4) 44 DW_CFA_offset r61 -24 (6 * -4) 46 DW_CFA_offset r60 -32 (8 * -4) 48 DW_CFA_offset r59 -40 (10 * -4) 50 DW_CFA_offset r58 -48 (12 * -4) 52 DW_CFA_offset r57 -56 (14 * -4) 54 DW_CFA_offset r56 -64 (16 * -4) 56 DW_CFA_offset r55 -72 (18 * -4) 58 DW_CFA_offset r54 -80 (20 * -4) 60 DW_CFA_offset r53 -88 (22 * -4) 62 DW_CFA_offset r52 -96 (24 * -4) 64 DW_CFA_offset r51 -104 (26 * -4) 66 DW_CFA_offset r50 -112 (28 * -4) 68 DW_CFA_offset r49 -120 (30 * -4) 70 DW_CFA_offset r48 -128 (32 * -4) 72 DW_CFA_offset r47 -136 (34 * -4) 74 DW_CFA_offset r46 -144 (36 * -4) 76 DW_CFA_register r70 = r12 79 DW_CFA_offset_extended_sf r65 4 (-1 * -4) 82 DW_CFA_advance_loc 32 (32 * 1) 83 DW_CFA_offset r5 -228 (57 * -4) 85 DW_CFA_offset r31 -148 (37 * -4) 87 DW_CFA_offset r30 -152 (38 * -4) 89 DW_CFA_offset r29 -156 (39 * -4) 91 DW_CFA_offset_extended r70 -220 (55 * -4) 94 DW_CFA_offset r6 -224 (56 * -4) 96 DW_CFA_nop
[llvm-bugs] [Bug 26835] clang crashes on valid code at -O1 and above on x86_64-linux-gnu: Assertion `isSimple() && "Expected a SimpleValueType!"' failed
https://llvm.org/bugs/show_bug.cgi?id=26835 Michael Kuperstein changed: What|Removed |Added Status|NEW |RESOLVED CC||michael.kuperst...@gmail.co ||m Resolution|--- |FIXED --- Comment #1 from Michael Kuperstein --- Fixed in r262746. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26845] New: crash of llvm-diff (Assertion `!Result && "structural differences second time around?"' failed)
https://llvm.org/bugs/show_bug.cgi?id=26845
Bug ID: 26845
Summary: crash of llvm-diff (Assertion `!Result && "structural
differences second time around?"' failed)
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: chengnian...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When I apply llvm-diff to the attached two bc files(t.c_003.bc and temp.bc),
llvm-diff crashes.
$: llvm-diff-trunk t.c_003.bc temp.bc
in function platform_main_end:
in block %entry:
in instruction store to %crc.addr / store to %crc.addr:
operands %crc.addr and %crc.addr differ
llvm-diff-trunk:
/tmp/llvm-builder/llvm-source-trunk/tools/llvm-diff/DifferenceEngine.cpp:179:
void {anonymous}::FunctionDifferenceEngine::unify(llvm::Instruction*,
llvm::Instruction*): Assertion `!Result && "structural differences second time
around?"' failed.
Aborted (core dumped)
$:
$: clang-trunk -v
clang version 3.9.0 (trunk 262593)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$:
$: llvm-diff-trunk -version
LLVM (http://llvm.org/):
LLVM version 3.9.0svn
Optimized build with assertions.
Built Mar 3 2016 (01:23:18).
Default target: x86_64-unknown-linux-gnu
Host CPU: nehalem
$:
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26742] llvm.eh.sjlj.setjmp builtin lowering may result in a compiler crash in pic mode
https://llvm.org/bugs/show_bug.cgi?id=26742 Quentin Colombet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Quentin Colombet --- I went ahead with the proposed workaround because this may crash the compiler or silently produce incorrect code. If someone has a bette fix, patches welcome :). Committed revision 262762. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26846] New: UBSan fails to deduplicate reports from template instantiations
https://llvm.org/bugs/show_bug.cgi?id=26846
Bug ID: 26846
Summary: UBSan fails to deduplicate reports from template
instantiations
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: vonos...@gmail.com
CC: llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Classification: Unclassified
Arguably, it should.
$ cat tmp/a.cc
#include
struct C {
void print(int x) { fprintf(stderr, "This is %d\n", x); }
};
template
void f(C* c, T t) {
c->print((int)t);
}
int main() {
C* c = NULL;
f(c, 2);
f(c, 3.0);
return 0;
}
$ ./bin/clang++ -fsanitize=null tmp/a.cc -O1 ; ./a.out
tmp/a.cc:9:3: runtime error: member call on null pointer of type 'C'
This is 2
tmp/a.cc:9:3: runtime error: member call on null pointer of type 'C'
This is 3
Sadly, we print the error twice for the exact same source location and type.
This what deduplication was implemented for, but for some reason it's not
triggering here, although the "static data" we pass to the handlers is exactly
the same:
$ ./bin/clang++ -fsanitize=null tmp/a.cc -O1 -S -emit-llvm -o a.ll
$ cat a.ll
<...>
@.src = private unnamed_addr constant [9 x i8] c"tmp/a.cc\00", align 1
@0 = private unnamed_addr constant { i16, i16, [4 x i8] } { i16 -1, i16 0, [4 x
i8] c"'C'\00" }
@1 = private unnamed_addr global { { [9 x i8]*, i32, i32 }, { i16, i16, [4 x
i8] }*, i64, i8 } { { [9 x i8]*, i32, i32 } { [9 x i8]* @.src, i32 9, i32 3 },
{ i16, i16, [4 x i8] }* @0, i64 0, i8 4 }
<>
@2 = private unnamed_addr global { { [9 x i8]*, i32, i32 }, { i16, i16, [4 x
i8] }*, i64, i8 } { { [9 x i8]*, i32, i32 } { [9 x i8]* @.src, i32 9, i32 3 },
{ i16, i16, [4 x i8] }* @0, i64 0, i8 4 }
define linkonce_odr void @_Z1fIiEvP1CT_(%struct.C* %c, i32 %t) #1 comdat {
<...>
tail call void @__ubsan_handle_type_mismatch(i8* bitcast ({ { [9 x i8]*, i32,
i32 }, { i16, i16, [4 x i8] }*, i64, i8 }* @1 to i8*), i64 %1) #4, !nosanitize
!1
<...>
}
define linkonce_odr void @_Z1fIdEvP1CT_(%struct.C* %c, double %t) #1 comdat {
<...>
tail call void @__ubsan_handle_type_mismatch(i8* bitcast ({ { [9 x i8]*, i32,
i32 }, { i16, i16, [4 x i8] }*, i64, i8 }* @2 to i8*), i64 %1) #4, !nosanitize
!1
<...>
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26847] New: coverage flushing unlocks and closes file in the wrong order
https://llvm.org/bugs/show_bug.cgi?id=26847
Bug ID: 26847
Summary: coverage flushing unlocks and closes file in the wrong
order
Product: compiler-rt
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: t...@cloudera.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When using GCDA profiling, the flush process tries to flock/funlock the GCDA
files to prevent multi-process races. However, the code that closes the file
seems to be wrong: it calls 'unlock' on the file _after_ closing it, which
results in EBADF:
open("/tmp/test.gcda", O_RDWR) = -1 ENOENT (No such file or directory)
open("/tmp/test.gcda", O_RDWR|O_CREAT, 0644) = 3
flock(3, LOCK_EX) = 0
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f2b2e397000
lseek(3, 0, SEEK_CUR) = 0
write(3, "adcg*204J\310\376B\0\0\0\1\5\0\0\0\0\0\0\0\211EN;\2\0\0\0"..., 124) =
124
close(3)= 0
munmap(0x7f2b2e397000, 4096)= 0
flock(3, LOCK_UN) = -1 EBADF (Bad file descriptor)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26848] New: Parser assertion failure when using -Weverything
https://llvm.org/bugs/show_bug.cgi?id=26848 Bug ID: 26848 Summary: Parser assertion failure when using -Weverything Product: clang Version: 3.7 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: st4ck0v3rf...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Attached are all files that were requested in the output. Reproduce with -Weverything -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26805] Register coalescer introduces verifier error
https://llvm.org/bugs/show_bug.cgi?id=26805 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Matthias Braun --- Fixed in r262768 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25969] Crash when compiling Unreal Engine
https://llvm.org/bugs/show_bug.cgi?id=25969 Victor Polevoy changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #16 from Victor Polevoy --- (In reply to comment #15) > (In reply to comment #14) > > This does not crash with a recent clang. > > > > $ source test-a50d6e.sh > > In file included from test.cpp:1: > > In file included from /usr/bin/../include/c++/v1/iostream:38: > > In file included from /usr/bin/../include/c++/v1/ios:216: > > In file included from /usr/bin/../include/c++/v1/__locale:15: > > /usr/bin/../include/c++/v1/string:1938:44: error: 'basic_string<_CharT, > > _Traits, _Allocator>' is missing exception specification > > 'noexcept(is_nothrow_copy_constructible::value)' > > basic_string<_CharT, _Traits, _Allocator>::basic_string(const > > allocator_type& __a) > >^ > > /usr/bin/../include/c++/v1/string:1326:40: note: previous declaration is > > here > > _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& > > __a) > >^ > > 1 error generated. > > > > Exception specification handling has changed since 3.7, and I think this has > > been fixed. > > It is not fixed. Just tried to compile UnrealEngine 4 on 3.7.1 and it > crashes with exactly same messages on 5-10 files of 872. It is better to reopen this bug and to investigate where is the problem. It looks like minimal example is difficult to make but this does not make this bug fixed because the problem still exists and annoys people. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
