[llvm-bugs] [Bug 32589] New: Crashing clang-4.0 on ubuntu
https://bugs.llvm.org/show_bug.cgi?id=32589
Bug ID: 32589
Summary: Crashing clang-4.0 on ubuntu
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mrdvlpr@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18254
--> https://bugs.llvm.org/attachment.cgi?id=18254&action=edit
C generated file
The following command will crash clang-4.0 on ubuntu 16.04 (note that this also
crashes 3.8 and 3.9)
$ python -c "print('{' * 9)" > test.c && clang-4.0 test.c
Output of the command:
test.c:1:1: error: expected identifier or '('
#0 0x7ffa3a2205e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x70e5e8)
#1 0x7ffa3a21e76e llvm::sys::RunSignalHandlers()
(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x70c76e)
#2 0x7ffa3a21e8bc (/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x70c8bc)
#3 0x7ffa3ca72390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x018e5ed2 clang::Lexer::LexTokenInternal(clang::Token&, bool)
(/usr/lib/llvm-4.0/bin/clang+0x18e5ed2)
#5 0x0194f218 clang::Preprocessor::Lex(clang::Token&)
(/usr/lib/llvm-4.0/bin/clang+0x194f218)
#6 0x00d63807
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib/llvm-4.0/bin/clang+0xd63807)
#7 0x00d63a9a
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib/llvm-4.0/bin/clang+0xd63a9a)
#8 0x00d63a9a
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib/llvm-4.0/bin/clang+0xd63a9a)
#9 0x00d63a9a
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib/llvm-4.0/bin/clang+0xd63a9a)
#10 0x00d63a9a
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib/llvm-4.0/bin/clang+0xd63a9a)
#11 0x00d63a9a
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib
(Recursion output)
(Recursion output)
(Recursion output)
#255 0x00d63a9a
clang::Parser::SkipUntil(llvm::ArrayRef,
clang::Parser::SkipUntilFlags) (/usr/lib/llvm-4.0/bin/clang+0xd63a9a)
Stack dump:
0. Program arguments: /usr/lib/llvm-4.0/bin/clang -cc1 -triple
x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name test.c -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/lib/llvm-4.0/bin/../lib/clang/4.0.0 -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-4.0/bin/../lib/clang/4.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 174
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/test-a00671.o -x c test.c
1. parser at unknown location
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 4.0.0-svn297204-1~exp1 (branches/release_40)
Target: x86_64-pc-linux-gnu
--
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 32590] New: clang::Parser::ParseDeclaratorInternal recursion crashing clang-4.0
https://bugs.llvm.org/show_bug.cgi?id=32590
Bug ID: 32590
Summary: clang::Parser::ParseDeclaratorInternal recursion
crashing clang-4.0
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mrdvlpr@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18255
--> https://bugs.llvm.org/attachment.cgi?id=18255&action=edit
Compiled file
The following command will crash clang-4.0 on ubuntu 16.04. (also 3.8 and 3.9)
$ python -c "print('*' * 9)" > test.c && clang-4.0 test.c
Output of command:
#0 0x7f1d6bef55e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x70e5e8)
#1 0x7f1d6bef376e llvm::sys::RunSignalHandlers()
(/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x70c76e)
#2 0x7f1d6bef38bc (/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1+0x70c8bc)
#3 0x7f1d6e747390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x00efb36a clang::DeclSpec::Finish(clang::Sema&,
clang::PrintingPolicy const&) (/usr/lib/llvm-4.0/bin/clang+0xefb36a)
#5 0x00d839b7
clang::Parser::ParseTypeQualifierListOpt(clang::DeclSpec&, unsigned int, bool,
bool) (/usr/lib/llvm-4.0/bin/clang+0xd839b7)
#6 0x00d8442f
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8442f)
#7 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#8 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#9 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#10 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#11 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#12 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#13 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
#14 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
...
... (recursion output)
...
#255 0x00d8445d
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&)) (/usr/lib/llvm-4.0/bin/clang+0xd8445d)
Stack dump:
0. Program arguments: /usr/lib/llvm-4.0/bin/clang -cc1 -triple
x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name test.c -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/lib/llvm-4.0/bin/../lib/clang/4.0.0 -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-4.0/bin/../lib/clang/4.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 174
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/test-73a5ff.o -x c test.c
1. test.c:1:19371: current parser token '*'
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 4.0.0-svn297204-1~exp1 (branches/release_40)
Target: x86_64-pc-linux-gnu
--
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 32591] New: opt crashes with "-simplifycfg -lcssa -loop-unswitch": Assertion `InLCSSA && "Requested to preserve LCSSA, but it's already broken."'
https://bugs.llvm.org/show_bug.cgi?id=32591 Bug ID: 32591 Summary: opt crashes with "-simplifycfg -lcssa -loop-unswitch": Assertion `InLCSSA && "Requested to preserve LCSSA, but it's already broken."' Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 18256 --> https://bugs.llvm.org/attachment.cgi?id=18256&action=edit csmith generated, bugpoint reduced reproducer opt -S -simplifycfg -lcssa -loop-unswitch red.ll gives opt: ../lib/Transforms/Utils/LoopSimplify.cpp:738: bool llvm::simplifyLoop(llvm::Loop *, llvm::DominatorTree *, llvm::LoopInfo *, llvm::ScalarEvolution *, llvm::AssumptionCache *, bool): Assertion `L->isRecursivelyLCSSAForm(*DT, *LI) && "Requested to preserve LCSSA, but it's already broken."' failed. Similar to PR31198 -- 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 32592] New: TestDataFormatterLibcxxListLoop fails with newer libc++
https://bugs.llvm.org/show_bug.cgi?id=32592 Bug ID: 32592 Summary: TestDataFormatterLibcxxListLoop fails with newer libc++ Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org The test relies on libc++ internals to test correct handling of corrupted linked lists. We should come up with a better way to test these kinds of scenarios. The most versatile solution would be to come up with some sort of unit test framework for data formatters. -- 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 32593] New: [mc] v_mov_fed_b32, s_endpgm_saved, s_wakeup, s_rfe_restore_b64 are not supported for VI
https://bugs.llvm.org/show_bug.cgi?id=32593 Bug ID: 32593 Summary: [mc] v_mov_fed_b32, s_endpgm_saved, s_wakeup, s_rfe_restore_b64 are not supported for VI Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org The following instructions are not supported for VI: - s_endpgm_saved - s_wakeup - s_rfe_restore_b64 - v_perm_b32 Also there are two instructions which are supported for SI/CI but not for VI: - v_mov_fed_b32 - v_mov_fed_b32_e64 -- 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 32594] New: Error with inline asm constraint "=A" on amd64
http://bugs.llvm.org/show_bug.cgi?id=32594 Bug ID: 32594 Summary: Error with inline asm constraint "=A" on amd64 Product: clang Version: 4.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: roy...@freebsd.org CC: llvm-bugs@lists.llvm.org Created attachment 18257 --> http://bugs.llvm.org/attachment.cgi?id=18257&action=edit Preprocessed C file When the "=A" inline asm constrain is used to generate x86 64bit code clang trows an internal error: $ cc -o test test.c fatal error: error in backend: Cannot select: t53: i64 = build_pair t51, t52 t51: i32,ch,glue = CopyFromReg t50, Register:i32 %EAX, t50:1 t31: i32 = Register %EAX t50: ch,glue = inlineasm t46, TargetExternalSymbol:i64'lock; cmpxchg16b $2', MDNode:ch<0x803b3e4a8>, TargetConstant:i64<25>, TargetConstant:i32<18>, Register:i32 %EAX, Register:i32 %EDX, TargetConstant:i32<196622>, FrameIndex:i64<1>, TargetConstant:i32<9>, Register:i64 %RCX, TargetConstant:i32<9>, Register:i64 %RBX, TargetConstant:i32<-2147483631>, Register:i32 %vreg6, Register:i32 %vreg7, TargetConstant:i32<196622>, FrameIndex:i64<1>, TargetConstant:i32<12>, Register:i32 %EFLAGS, t46:1 t27: i64 = TargetExternalSymbol'lock; cmpxchg16b $2' t29: i64 = TargetConstant<25> t30: i32 = TargetConstant<18> t31: i32 = Register %EAX t32: i32 = Register %EDX t33: i32 = TargetConstant<196622> t3: i64 = FrameIndex<1> t36: i32 = TargetConstant<9> t34: i64 = Register %RCX t36: i32 = TargetConstant<9> t37: i64 = Register %RBX t47: i32 = TargetConstant<-2147483631> t43: i32 = Register %vreg6 t45: i32 = Register %vreg7 t33: i32 = TargetConstant<196622> t3: i64 = FrameIndex<1> t48: i32 = TargetConstant<12> t49: i32 = Register %EFLAGS t46: ch,glue = CopyToReg t38, Register:i32 %vreg7, t93, t44:1 t45: i32 = Register %vreg7 t93: i32 = truncate t92 t92: i64 = srl t72, Constant:i8<32> t72: i64,ch = load t81, t24, undef:i64 t24: i64,ch = load t81, FrameIndex:i64<2>, undef:i64 t9: i64 = FrameIndex<2> t5: i64 = undef t5: i64 = undef t91: i8 = Constant<32> t44: ch,glue = CopyToReg t38, Register:i32 %vreg6, t90, t38:1 t43: i32 = Register %vreg6 t90: i32 = truncate t72 t72: i64,ch = load t81, t24, undef:i64 t24: i64,ch = load t81, FrameIndex:i64<2>, undef:i64 t9: i64 = FrameIndex<2> t5: i64 = undef t5: i64 = undef t38: ch,glue = CopyToReg t35, Register:i64 %RBX, t23, t35:1 t37: i64 = Register %RBX t23: i64,ch = load t81, FrameIndex:i64<4>, undef:i64 t15: i64 = FrameIndex<4> t5: i64 = undef t35: ch,glue = CopyToReg t26, Register:i64 %RCX, t22 t34: i64 = Register %RCX t22: i64,ch = load t81, t73, undef:i64 t73: i64 = or FrameIndex:i64<4>, Constant:i64<8> t15: i64 = FrameIndex<4> t20: i64 = Constant<8> t5: i64 = undef t52: i32,ch,glue = CopyFromReg t51:1, Register:i32 %EDX, t51:2 t32: i32 = Register %EDX t51: i32,ch,glue = CopyFromReg t50, Register:i32 %EAX, t50:1 t31: i32 = Register %EAX t50: ch,glue = inlineasm t46, TargetExternalSymbol:i64'lock; cmpxchg16b $2', MDNode:ch<0x803b3e4a8>, TargetConstant:i64<25>, TargetConstant:i32<18>, Register:i32 %EAX, Register:i32 %EDX, TargetConstant:i32<196622>, FrameIndex:i64<1>, TargetConstant:i32<9>, Register:i64 %RCX, TargetConstant:i32<9>, Register:i64 %RBX, TargetConstant:i32<-2147483631>, Register:i32 %vreg6, Register:i32 %vreg7, TargetConstant:i32<196622>, FrameIndex:i64<1>, TargetConstant:i32<12>, Register:i32 %EFLAGS, t46:1 t27: i64 = TargetExternalSymbol'lock; cmpxchg16b $2' t29: i64 = TargetConstant<25> t30: i32 = TargetConstant<18> t31: i32 = Register %EAX t32: i32 = Register %EDX t33: i32 = TargetConstant<196622> t3: i64 = FrameIndex<1> t36: i32 = TargetConstant<9> t34: i64 = Register %RCX t36: i32 = TargetConstant<9> t37: i64 = Register %RBX t47: i32 = TargetConstant<-2147483631> t43: i32 = Register %vreg6 t45: i32 = Register %vreg7 t33: i32 = TargetConstant<196622> t3: i64 = FrameIndex<1> t48: i32 = TargetConstant<12> t49: i32 = Register %EFLAGS t46: ch,glue = CopyToReg t38, Register:i32 %vreg7, t93, t44:1 t45: i32 = Register %vreg7 t93: i32 = truncate t92 t92: i64 = srl t72, Constant:i8<32> t72: i64,ch = load t81, t24, und
[llvm-bugs] [Bug 32568] Bad code generation with cmpxchg16b and __uint128_t
http://bugs.llvm.org/show_bug.cgi?id=32568 Roger changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Roger --- 32594 contains a clearer description of the problem. *** This bug has been marked as a duplicate of bug 32594 *** -- 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 32406] SLP regression on SystemZ
https://bugs.llvm.org/show_bug.cgi?id=32406 Jonas Paulsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Jonas Paulsson --- This particular case was handled by improving the cost functions by understanding that target has an extending scalar load that is cheaper. See https://reviews.llvm.org/D29631 (BasicTTIImpl.h) -- 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 32459] apparent thread race condition crash in lld 4.0.0
http://bugs.llvm.org/show_bug.cgi?id=32459 ema...@freebsd.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from ema...@freebsd.org --- Sorry for the false alarm. It appears this is due to a FreeBSD kernel issue with an as-yet-uncommitted change to the FreeBSD virtual memory subsystem. -- 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 32595] New: gcc-compat check wrongly complains about differing behaviour
http://bugs.llvm.org/show_bug.cgi?id=32595
Bug ID: 32595
Summary: gcc-compat check wrongly complains about differing
behaviour
Product: clang
Version: 4.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: roy...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Created attachment 18260
--> http://bugs.llvm.org/attachment.cgi?id=18260&action=edit
Sample test case
Hello,
The attached code triggers the following clang warning:
test.c:25:16: warning: 'break' is bound to loop, GCC binds it to switch
[-Wgcc-compat]
while (foo(++i)) {
^
test.c:14:9: note: expanded from macro 'foo'
break; \
^
I haven't been able to spot what this different behaviour is, I've compiled the
attached test with clang 3.8, gcc 4.6 and gcc 5.4 and the output is always the
same:
D
i: 1
D
i: 2
D
i: 3
E
END
Also, I'm not sure what clang complains about, I don't think there's any
ambiguity here, and the "break" should apply to the inner switch. Could someone
clarify what's wrong with this, and how this should be fixed?
Note that the attached test.c is a simplification of an issue seen while
building Xen, in which case using a macro makes sense [0][1].
Roger.
[0]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/dm.c;h=d72b7bd8357e9d7f37be4f3ea0d1e6eac1ab4540;hb=refs/heads/staging#l411
[1]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/asm-x86/atomic.h;h=2fbe70551898bf4e8a866d9339eaf20d91991f9b;hb=refs/heads/staging#l46
--
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 10002] [opencl] Wrongfully assuming RHS is always unsigned
https://bugs.llvm.org/show_bug.cgi?id=10002 Eli Friedman changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #14 from Eli Friedman --- Yes, the behavior is correct here; closing. -- 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 32597] New: [PPC] Instruction with invalid TBR number decoded as valid.
https://bugs.llvm.org/show_bug.cgi?id=32597 Bug ID: 32597 Summary: [PPC] Instruction with invalid TBR number decoded as valid. Product: libraries Version: 3.9 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: nholc...@wisc.edu CC: llvm-bugs@lists.llvm.org The instruction `mftb 26, 327` from bytes `7f 47 52 e6` has an invalid second operand. Using gas to compile the instruction results in the error "Invalid tbr number". The second operand can only be 267 or 268. Bytes: 7f 47 52 e6 Expected decoding: invalid Actual decoding: mftb 26, 327 -- 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 32598] New: SIGSEGV on recursive templates
https://bugs.llvm.org/show_bug.cgi?id=32598
Bug ID: 32598
Summary: SIGSEGV on recursive templates
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: vanya...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
clang 4.0 crashes on this code:
template
auto accept() -> decltype(Predicate::template requires());
struct TypePredicate
{
template
static auto requires() -> decltype(accept());
};
void bar()
{
accept();
}
Previous compiler versions correctly showed an error on this code.
--
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 32599] New: Merge r298569into the 4.0 branch
http://bugs.llvm.org/show_bug.cgi?id=32599 Bug ID: 32599 Summary: Merge r298569into the 4.0 branch Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Merge https://reviews.llvm.org/rL298569 to the 4.0.1 branch. Related bug: https://bugs.llvm.org/show_bug.cgi?id=32586 -- 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 32600] New: [PPC] Decoded branch operand out of range
https://bugs.llvm.org/show_bug.cgi?id=32600 Bug ID: 32600 Summary: [PPC] Decoded branch operand out of range Product: libraries Version: 3.9 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: nholc...@wisc.edu CC: llvm-bugs@lists.llvm.org Using LLVM to decode ppc64 instructions, the BT instruction operand can be decoded as an out-of-range value. Bytes: 41 80 80 00 Expected: bt 0, .-32768 Actual: bt 0, .+32768 Trying to assemble the decoding produced by LLVM using gas produced the error: operand out of range (0x8000 is not between 0x8000 and 0x7ffc) -- 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 32601] New: r298532
http://bugs.llvm.org/show_bug.cgi?id=32601 Bug ID: 32601 Summary: r298532 Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Merge https://reviews.llvm.org/rL298532 and https://reviews.llvm.org/rL298570 to the 4.0.1 branch. This is not a bug fix but an improvement to improve compatibility with GNU libtools. I believe this is quite low-risk to merge into the stable branch. -- 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 32602] New: Merge r298532 into the 4.0 branch
http://bugs.llvm.org/show_bug.cgi?id=32602 Bug ID: 32602 Summary: Merge r298532 into the 4.0 branch Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Merge https://reviews.llvm.org/rL298532 to the 4.0.1 branch. This is another change to improve compatibility with GNU libtools. -- 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 32603] New: [lld-link] Spourious duplicate symbol error
https://bugs.llvm.org/show_bug.cgi?id=32603 Bug ID: 32603 Summary: [lld-link] Spourious duplicate symbol error Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: alberto.ma...@microsoft.com CC: llvm-bugs@lists.llvm.org Created attachment 18261 --> https://bugs.llvm.org/attachment.cgi?id=18261&action=edit Reproducer and possible fix. We have noticed an inconsistency between the link.exe and lld-link.exe Consider this example: foo1.ll defines a function foo foo2.ll defines a function foo main.ll contains main that calls foo foo1.ll is assembled into an object file and then into a library foo2.ll is assembled into an object file The following command currently fails: lld-link.exe foo1.lib main.obj foo2.obj The error is: duplicate symbol: foo While the same invocation works with link.exe This is because link processes all .obj files in input first and resorts to .lib inputs only if there are unresolved symbols. Since the symbol foo is found in the .obj the library is ignored and no error is reported. A reproducer for this bug is attached in the format of an LLVM test. The same diff file contains a possible fix. -- 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 31153] unordered_set's operator= or insert() is slower without a reserve before it
http://bugs.llvm.org/show_bug.cgi?id=31153 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Marshall Clow (home) --- Closing as "not a bug". Please reopen if you have/find more information. -- 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 20651] ::operator new(size_t) should assert in -fno-exceptions
http://bugs.llvm.org/show_bug.cgi?id=20651 Marshall Clow (home) changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #7 from Marshall Clow (home) --- > Otherwise, I think we should probably close this as "INVALID" Doing so. -- 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 32604] New: x86_64 codegen checks branch conditions in the wrong order
https://bugs.llvm.org/show_bug.cgi?id=32604
Bug ID: 32604
Summary: x86_64 codegen checks branch conditions in the wrong
order
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: d...@su-root.co.uk
CC: llvm-bugs@lists.llvm.org
Created attachment 18262
--> https://bugs.llvm.org/attachment.cgi?id=18262&action=edit
Example program that clang++ miscompiles on x86_64
Clang 3.9.0 and 4.0 incorrectly compiles the attached program.
The problem is this branch
```
bool not_initialized;
int a = 5;
int b = 5;
int c = 5;
if (xxx(&c, &a, &b, not_initialized) && not_initialized) {
printf("true\n");
} else {
printf("false\n");
}
```
The function `xxx()` is not guaranteed to initialize the `bool` variable
`not_initialized`. In this program `a`, `b`, and `c` are set up so that
`not_initialized` never gets initialized. However this should not be a problem
because the function `xxx` returns false in this case so the value of
`not_initialized` should never be read.
However the code generated by clang at -O1 does the wrong thing. It branches on
the value of `not_initialized` first before trying to branch on the return
value of `xxx()`. This is wrong because the order of the `&&` operator in the
if condition is not being respected.
Here is the output of `objdump -d --no-show-raw-insn`
```
00400530 <_Z3foov>:
400530: sub$0x18,%rsp
400534: movl $0x5,0x14(%rsp)
40053c: movl $0x5,0x10(%rsp)
400544: movl $0x5,0xc(%rsp)
40054c: lea0xc(%rsp),%rdi
400551: lea0x14(%rsp),%rsi
400556: lea0x10(%rsp),%rdx
40055b: lea0xb(%rsp),%rcx
400560: callq 400510 <_Z3xxxPiS_S_Rb>
400565: cmpb $0x0,0xb(%rsp)
40056a: je 400577 <_Z3foov+0x47>
40056c: xor$0x1,%al
40056e: jne400577 <_Z3foov+0x47>
400570: mov$0x400637,%edi
400575: jmp40057c <_Z3foov+0x4c>
400577: mov$0x400631,%edi
40057c: callq 400400
400581: add$0x18,%rsp
400585: retq
400586: nopw %cs:0x0(%rax,%rax,1)
```
You can see that after `callq 400510 <_Z3xxxPiS_S_Rb>` the next instruction
`cmpb $0x0,0xb(%rsp)` which is doing a comparison on a stack location which
is the `not_initialized` bool and then a few instructions later a comparison is
done on the return value of the call (`xor$0x1,%al`). This is the wrong
order.
You can tell that `0xb(%rsp)` is the `not_initialized` variable because we can
see it being passed as the forth parameter ( `lea0xb(%rsp),%rcx` ) to the
function call.
For convenience here's a link to the problematic program on godbolt
https://godbolt.org/g/piH3yO
--
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 32604] x86_64 codegen checks branch conditions in the wrong order
https://bugs.llvm.org/show_bug.cgi?id=32604 Dan Liew changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Dan Liew --- After talking it over with a few people I don't think this is really a bug. >From the perspective of the original program no new or incorrect behaviour can be observed from within the program. I was also silly in thinking that doing something at the assembly level that would be undefined behaviour in the source language is considered undefined at the assembly level. However it should be noted that branching on non initialized memory at the assembly level might lead to non-determinism in the sequence of instructions that are executed. This "might" be observable externally if someone was doing some sort of tracing at the binary level. -- 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 32605] New: common_type is not SFINAE-friendly
http://bugs.llvm.org/show_bug.cgi?id=32605
Bug ID: 32605
Summary: common_type is not SFINAE-friendly
Product: libc++
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: rs2...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The current implementation
template
struct _LIBCPP_TEMPLATE_VIS common_type<_Tp>
{
typedef typename common_type<_Tp, _Tp>::type type;
};
is incorrect, because common_type<_Tp, _Tp>::type need not exist, in which case
the current implementation will cause a hard error. This is the case for
abominable function types (although they currently fail due to a separate bug
in std::decay), and user-defined specializations may also fail to supply a
::type member. P0548 requires this case to be SFINAE-friendly.
--
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 32606] New: std::decay mishandles abominable function types
http://bugs.llvm.org/show_bug.cgi?id=32606
Bug ID: 32606
Summary: std::decay mishandles abominable function types
Product: libc++
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: rs2...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The current implementation causes a hard error when given an abominable
function type like 'int () const' because the non-taken branch of the
std::conditional ('typename remove_extent<_Up>::type*') attempts to form a
pointer to it:
template
struct _LIBCPP_TEMPLATE_VIS decay
{
private:
typedef typename remove_reference<_Tp>::type _Up;
public:
typedef typename conditional
<
is_array<_Up>::value,
typename remove_extent<_Up>::type*,
typename conditional
<
is_function<_Up>::value,
typename add_pointer<_Up>::type,
typename remove_cv<_Up>::type
>::type
>::type type;
};
--
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 32607] New: Crash in NewGVN if run after LICM
http://bugs.llvm.org/show_bug.cgi?id=32607
Bug ID: 32607
Summary: Crash in NewGVN if run after LICM
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: k...@alumni.harvard.edu
CC: llvm-bugs@lists.llvm.org
Consider the following bugpoint-reduced test case:
```
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "bugpoint-output-0d3dd22.bc"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define hidden void @"julia_populate_gal_fsm!_20586"() #0 {
top:
br label %if
if: ; preds = %if, %top
%0 = load double, double* undef, align 8, !tbaa !1, !noalias !5
%1 = fadd double %0, undef
store double %1, double* undef, align 8, !tbaa !1, !noalias !5
br i1 false, label %L50, label %if
L50: ; preds = %if
ret void
}
attributes #0 = { "no-frame-pointer-elim"="true" }
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"Debug Info Version", i32 3}
!1 = !{!2, !2, i64 0}
!2 = !{!"jtbaa_arraybuf", !3, i64 0}
!3 = !{!"jtbaa_data", !4, i64 0}
!4 = !{!"jtbaa"}
!5 = !{!6}
!6 = !{!"aliasscope", !7}
!7 = !{!"accum_galaxy_pos!"}
```
```
opt -licm -newgvn bugpoint-reduced-simplified.ll
opt: /home/ubuntu/llvm/lib/Transforms/Scalar/NewGVN.cpp:2167: void
{anonymous}::NewGVN::updateProcessedCount(llvm::Value*): Assertion
`ProcessedCount[V] < 100 && "Seem to have processed the same Value a lot"'
failed.
```
Now, before bugpoint, the failure looked different (and the input wasn't an
infinite loop), so this is possibly just something that bugpoint exposed, but I
can rerun on the original file once this is fixed.
--
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 32608] New: Post RA scheduler incorrectly renames callee saved register
https://bugs.llvm.org/show_bug.cgi?id=32608
Bug ID: 32608
Summary: Post RA scheduler incorrectly renames callee saved
register
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: ASSIGNED
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: car...@google.com
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
Compile the following code with options
-fno-exceptions '-mcpu=power8' -O2 '-std=gnu++11'
class StringPiece {
public:
StringPiece(const char* data, int len): ptr_(data), length_(len) {}
int find(const char* s, int pos = 0);
const char* ptr_;
int length_;
};
bool foo(const char* hostname, int hostname_len) {
if (hostname_len <= 0)
return false;
const char* hostname_end = hostname + hostname_len;
if ((hostname_end[-1] == ' '))
return false;
if ((hostname[0] == '.') || (hostname_end[-2] == '.'))
return false;
if (hostname_len >= 4 && StringPiece(hostname, hostname_len).find("..", 0) !=
-1)
return false;
return true;
}
LLVM at revision r298955 generates following code for the later part of the
function
...
std 30, 48(1) # 8-byte Folded Spill
li 30, 0
addi 4, 3, .L.str@toc@l
addi 3, 1, 32
bl _ZN11StringPiece4findEPKci
nop
li 4, 1
cmpwi 0, 3, -1
ld 12, 48(1)# 8-byte Folded Reload
isel 3, 4, 30, 2
addi 1, 1, 64
ld 0, 16(1)
mtlr 0
blr
The instruction
ld 12, 48(1)
should be
ld 30, 48(1)
and moved after isel.
The problem can't be reproduced without patch r298955, but the bug is still
there.
The root cause is in post RA scheduler, llvm tries to break anti/output
dependence with register renaming. But for callee saved register restore
instruction, there is no explicit use of the register, simply rename the load
instruction can't restore the value of the register correctly.
We should not rename the callee saved register restore instruction.
--
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 32609] New: LLD COFF /MAP option not supported
https://bugs.llvm.org/show_bug.cgi?id=32609 Bug ID: 32609 Summary: LLD COFF /MAP option not supported Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: ignacio.slipk...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, this option is not supported by LLD 4.0 I use a commercial product that reads .map files generated by Visual Studio's linker, however lld doesn't support this option (if it did they should also be generated in the same format). I can't patch the commercial product so it would be great if this feature was added. -- 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 32606] std::decay mishandles abominable function types
http://bugs.llvm.org/show_bug.cgi?id=32606 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Marshall Clow (home) --- Fixed in revision 299894. -- 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 32610] New: clang crashes on valid code at -Os and above (in 32-bit mode) running pass 'X86 DAG->DAG Instruction Selection': Assertion `Sequence.size() - Noops == ScheduledNodes && "T
http://bugs.llvm.org/show_bug.cgi?id=32610 Bug ID: 32610 Summary: clang crashes on valid code at -Os and above (in 32-bit mode) running pass 'X86 DAG->DAG Instruction Selection': Assertion `Sequence.size() - Noops == ScheduledNodes && "The number of nodes scheduled doesn't match the expected number!"' failed Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org This appears to be a recent regression, and the crash only triggers in the 32-bit mode, but not in the 64-bit mode. $ clang -v clang version 5.0.0 (trunk 299862) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.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.4 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 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-4.0.0 -m32 -Os small.c $ clang -m64 -Os small.c $ $ clang -m32 -Os small.c clang-5.0: /tmp/llvm-builder/llvm-source-trunk/lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp:696: void llvm::ScheduleDAGSDNodes::VerifyScheduledSequence(bool): Assertion `Sequence.size() - Noops == ScheduledNodes && "The number of nodes scheduled doesn't match the expected number!"' failed. #0 0x01fa193a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-5.0+0x1fa193a) #1 0x01f9f6be llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-5.0+0x1f9f6be) #2 0x01f9f832 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-5.0+0x1f9f832) #3 0x7ff6a27cd390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #4 0x7ff6a1540428 gsignal /build/glibc-9tT8Do/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0 #5 0x7ff6a154202a abort /build/glibc-9tT8Do/glibc-2.23/stdlib/abort.c:91:0 #6 0x7ff6a1538bd7 __assert_fail_base /build/glibc-9tT8Do/glibc-2.23/assert/assert.c:92:0 #7 0x7ff6a1538c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82) #8 0x027cc285 (/usr/local/clang-trunk/bin/clang-5.0+0x27cc285) #9 0x027ca19f (anonymous namespace)::ScheduleDAGRRList::Schedule() (/usr/local/clang-trunk/bin/clang-5.0+0x27ca19f) #10 0x0274f33c llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/local/clang-trunk/bin/clang-5.0+0x274f33c) #11 0x02759ba9 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/clang-trunk/bin/clang-5.0+0x2759ba9) #12 0x0275b9c1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .part.735] [clone .constprop.758] (/usr/local/clang-trunk/bin/clang-5.0+0x275b9c1) #13 0x013f6ed4 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/clang-trunk/bin/clang-5.0+0x13f6ed4) #14 0x018092b5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-5.0+0x18092b5) #15 0x01b0ba73 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-5.0+0x1b0ba73) #16 0x01b0bb3c llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang-5.0+0x1b0bb3c) #17 0x01b0b5dd llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang-5.0+0x1b0b5dd) #18 0x0215cc70 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::La
[llvm-bugs] [Bug 32611] New: PowerPC - unexpected handler being optimized out
https://bugs.llvm.org/show_bug.cgi?id=32611 Bug ID: 32611 Summary: PowerPC - unexpected handler being optimized out Product: new-bugs Version: 4.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: eric.schwe...@pgroup.com CC: llvm-bugs@lists.llvm.org Created attachment 18265 --> https://bugs.llvm.org/attachment.cgi?id=18265&action=edit reproduce the unexpected handler issue This happens in the release_40 branch. % clang++ unexpected.cpp -O3 % a.out terminate called after throwing an instance of 'int' Aborted % clang++ unexpected.cpp -O0 % a.out Unexpected handler was called. terminate called after throwing an instance of 'int' Aborted g++ and the x86 backend generate the latter output as well. -- 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 32605] common_type is not SFINAE-friendly
http://bugs.llvm.org/show_bug.cgi?id=32605 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Marshall Clow (home) --- Fixed in revision 299901 -- 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 32612] New: LLD COFF Crash in COFF\Writer.cpp (Writer::run)
https://bugs.llvm.org/show_bug.cgi?id=32612 Bug ID: 32612 Summary: LLD COFF Crash in COFF\Writer.cpp (Writer::run) Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: ignacio.slipk...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, I get a crash on line 307 of Writer.cpp (LLD 4.0.0): if (!Config->PDBPath.empty()) createPDB(Config->PDBPath, Symtab, SectionTable, BuildId->DI); This happens because BuildId is NULL. -- 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 32613] New: LLD COFF /LTCG option not supported
https://bugs.llvm.org/show_bug.cgi?id=32613 Bug ID: 32613 Summary: LLD COFF /LTCG option not supported Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: ignacio.slipk...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, the /LTCG (Link Time Code Generation) option isn't supported in LLD 4.0.0 I believe this option is enabled by default in Visual Studio. -- 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 32613] LLD COFF /LTCG option not supported
https://bugs.llvm.org/show_bug.cgi?id=32613 Rui Ueyama changed: What|Removed |Added Resolution|--- |WONTFIX CC||r...@google.com Status|NEW |RESOLVED --- Comment #1 from Rui Ueyama --- The /LTCG option is to make the linker generate code at link-time. This needs coordination between a compiler and a linker. MSVC's cl.exe and link.exe uses some intermediate representation of code to generate code. And that intermediate code is highly compiler-dependent. So it is not supported by our compiler nor linker. We instead support LTO (link-time optimization) which is the same feature as LTCG. Just like cl.exe and link.exe, you need to use clang-cl.exe and lld-link.exe to use LTO. You want to use LTO instead of LTCG. -- 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 32485] Invalid PPC CTR loop with 128bit integers
https://bugs.llvm.org/show_bug.cgi?id=32485 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hal Finkel --- Fixed in r299910. -- 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 32157] getRecipEstimate may not generate a reciprocal inside of a loop
https://bugs.llvm.org/show_bug.cgi?id=32157 vit9696 changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from vit9696 --- Thanks for merging! I will hopefully continue exploring the slowdown issue a little further when I get a few more free minutes. Last time I checked it out it was due to an extra register increment which was not necessary. However, this does not have anything to do with the hoisting problem described here, and thus I am closing it as resolved. -- 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 32614] New: ICF causes section ordering to segfault on ARM
https://bugs.llvm.org/show_bug.cgi?id=32614 Bug ID: 32614 Summary: ICF causes section ordering to segfault on ARM Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: smee...@fb.com CC: llvm-bugs@lists.llvm.org % cat reduced.s .section.text.f,"axG",%progbits,f,comdat .code 32 f: .fnstart bx lr .fnend .section.text.g,"axG",%progbits,g,comdat .code 32 g: .fnstart bx lr .fnend % clang -target armv7-linux-gnueabi -shared -nostdlib -fuse-ld=lld -Xlinker --icf=all -o /dev/null reduced.s (lld crashes during the link) The assembly is reduced from a C++ source file, so it may not be 100% sensible (I got rid of a bunch of directives), but it reproduces the segfault. It occurs in compareByFilePosition [1] because of AOut being null. My understanding is that, because of ICF, only one of f and g will actually be output, hence the OutSec for the other will be null. Adding null checks before the SectionIndex comparison should get rid of the segfault, but I'm not sure if there's a better solution. [1] https://reviews.llvm.org/diffusion/L/browse/lld/trunk/ELF/OutputSections.cpp;299911$82?color=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 32615] New: executable coredump under ubuntu 14.04 libgcc 4.8
https://bugs.llvm.org/show_bug.cgi?id=32615
Bug ID: 32615
Summary: executable coredump under ubuntu 14.04 libgcc 4.8
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: m...@steazzalini.it
CC: llvm-bugs@lists.llvm.org
Considering the following source code:
#include
#include
int main() {
using namespace std;
const auto p = pow(1, 2);
cout << p;
}
Compiliing it with:
clang++-4.0 test.cpp -o test -std=c++1z -stdlib=libc++ -fuse-ld=lld -static
-lc++ -lc++abi -lpthread
Everything compiles without problems but executing test results in a coredump.
Using ld instead of lld solves the problem.
Omitting -static -lc++ -lc++abi -lpthread also works fine.
This is strictly related with ubuntu 14.04 using libgcc 4.8
// Stefano
--
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
