[llvm-bugs] [Bug 46771] New: compiler crash when code generation for AVR target
https://bugs.llvm.org/show_bug.cgi?id=46771
Bug ID: 46771
Summary: compiler crash when code generation for AVR target
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: s.pitchum...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 23751
--> https://bugs.llvm.org/attachment.cgi?id=23751&action=edit
test case run script generated by clang
testcase:
struct st
{
int m1;
int m2;
} obj;
struct st foo ()
{
return obj;
}
int main()
{
struct st l = foo();
return l.m1;
}
Command line: clang ret-st.c --target=avr -mmcu=atmega128 -c
Crash backtrace:
clang: /home/parallels/code/llvm-project.git/llvm/lib/IR/Constants.cpp:2028:
static llvm::Constant* llvm::ConstantExpr::getBitCast(llvm::Constant*,
llvm::Type*, bool): Assertion `CastInst::castIsValid(Instruction::BitCast, C,
DstTy) && "Invalid constantexpr bitcast!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: ./bin/clang ../ret-st.c --target=avr -mmcu=atmega128
-c
1. parser at end of file
2. ../ret-st.c:10:5: LLVM IR generation of declaration 'main'
3. ../ret-st.c:10:5: Generating code for declaration 'main'
#0 0x7fbe9e3bbc8a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/parallels/code/llvm-project.git/llvm/lib/Support/Unix/Signals.inc:568:0
#1 0x7fbe9e3b9aba llvm::sys::RunSignalHandlers()
/home/parallels/code/llvm-project.git/llvm/lib/Support/Signals.cpp:68:0
#2 0x7fbe9e3ba2db llvm::sys::CleanupOnSignal(unsigned long)
/home/parallels/code/llvm-project.git/llvm/lib/Support/Unix/Signals.inc:361:0
#3 0x7fbe9e2df000 HandleCrash
/home/parallels/code/llvm-project.git/llvm/lib/Support/CrashRecoveryContext.cpp:75:0
#4 0x7fbe9e2df000 CrashRecoverySignalHandler(int)
/home/parallels/code/llvm-project.git/llvm/lib/Support/CrashRecoveryContext.cpp:382:0
#5 0x7fbea51770e0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x110e0)
#6 0x7fbe9d07afff raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fff)
#7 0x7fbe9d07c42a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3442a)
#8 0x7fbe9d073e67 (/lib/x86_64-linux-gnu/libc.so.6+0x2be67)
#9 0x7fbe9d073f12 (/lib/x86_64-linux-gnu/libc.so.6+0x2bf12)
#10 0x7fbe9e42a847
(/home/parallels/llvm-avr/build/bin/../lib/libLLVM-12git.so+0x7a6847)
#11 0x7fbea2d7e657
clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef,
llvm::Type*, clang::GlobalDecl, bool, bool, bool, llvm::AttributeList,
clang::CodeGen::ForDefinition_t)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CodeGenModule.cpp:3215:0
#12 0x7fbea2d7f566
clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl,
llvm::Type*, bool, bool, clang::CodeGen::ForDefinition_t)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CodeGenModule.cpp:3353:0
#13 0x7fbea2b922cb clang::FunctionDecl::hasWrittenPrototype() const
/home/parallels/code/llvm-project.git/clang/include/clang/AST/Decl.h:2177:0
#14 0x7fbea2b922cb clang::FunctionDecl::hasPrototype() const
/home/parallels/code/llvm-project.git/clang/include/clang/AST/Decl.h:2172:0
#15 0x7fbea2b922cb EmitFunctionDeclPointer(clang::CodeGen::CodeGenModule&,
clang::GlobalDecl)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGExpr.cpp:2517:0
#16 0x7fbea2b92660
clang::CodeGen::CGCallee::CGCallee(clang::CodeGen::CGCalleeInfo const&,
llvm::Value*)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGCall.h:115:0
#17 0x7fbea2b92660 clang::CodeGen::CGCallee::forDirect(llvm::Constant*,
clang::CodeGen::CGCalleeInfo const&)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGCall.h:136:0
#18 0x7fbea2b92660 EmitDirectCallee(clang::CodeGen::CodeGenFunction&,
clang::GlobalDecl) (.isra.1162)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGExpr.cpp:4791:0
#19 0x7fbea2bace6f clang::CodeGen::CodeGenFunction::EmitCallee(clang::Expr
const*)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGExpr.cpp:4812:0
#20 0x7fbea2bace0f clang::CodeGen::CodeGenFunction::EmitCallee(clang::Expr
const*)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGExpr.cpp:4844:0
#21 0x7fbea2bad121
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot)
/home/parallels/code/llvm-project.git/clang/lib/CodeGen/CGExpr.cpp:4756:0
#22 0x7fbea2badc37 clang::CodeGen::RValue
llvm::function_ref::callback_fn<(anonymous
namespace)::AggExprEmitter::VisitCallExpr(clang::CallExpr
const*)::'lambda'(clang::CodeGen::ReturnValueSlot)>(long,
clang::CodeGen::ReturnValueSlot)
/home/parallels/code/llvm-project.git/llvm/include/llvm/ADT/STLExtras.h
[llvm-bugs] [Bug 46772] New: Overly dramatic error when trying to use wrong mcmodel with aarch64 targets.
https://bugs.llvm.org/show_bug.cgi?id=46772 Bug ID: 46772 Summary: Overly dramatic error when trying to use wrong mcmodel with aarch64 targets. Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: kacper.slominsk...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 23752 --> https://bugs.llvm.org/attachment.cgi?id=23752&action=edit empty-8d13f1.sh When compiling any bit of code (even an empty file) with for example "-target aarch64-none-elf" or any other aarch64 target, if "-mcmodel=kernel" is specified, the compiler prints an overly dramatic fatal error with a stack trace, and a plea to submit a bug report. Sample output (no, there actually is no stack trace printed in this case for whatever reason): $ touch empty.cpp $ clang++ -target aarch64-none-elf -mcmodel=kernel empty.cpp fatal error: error in backend: Only small, tiny and large code models are allowed on AArch64 clang-10: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 10.0.0 Target: aarch64-none-unknown-elf Thread model: posix InstalledDir: /usr/bin clang-10: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script. clang-10: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-10: note: diagnostic msg: /tmp/empty-8d13f1.cpp clang-10: note: diagnostic msg: /tmp/empty-8d13f1.sh clang-10: note: diagnostic msg: $ Attached is the empty-8d13f1.sh file; following is the empty-8d13f1.cpp contents: # 1 "" # 1 "empty.cpp" -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46773] New: Performance regression for sqrt, sqrtf, sqrtl in for loop
https://bugs.llvm.org/show_bug.cgi?id=46773
Bug ID: 46773
Summary: Performance regression for sqrt, sqrtf, sqrtl in for
loop
Product: new-bugs
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: joshstoc...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
This might actually be a twofer.
Consider the following function, which calculates the number of primes up to
10,000,000:
void primes() {
uint32_t NUM = 1000;
uint32_t total = 1;
for (uint32_t N = 3; N < NUM; N += 2) {
uint32_t prime = 1;
for (uint32_t f = 3; f <= (uint32_t)sqrtf(N); f += 2) {
if (N % f == 0) {
prime = 0;
break;
}
}
total += prime;
}
printf("Total primes: %d\n", total);
}
Note the for loop with sqrt (this also applies to sqrtf and sqrtl):
for (uint32_t f = 3; f <= (uint32_t)sqrt(N); f += 2)
First optimization bug: LLVM doesn't seem to recognize sqrt* as pure functions,
and so doesn't pull them out of the condition--instead, the sqrt operation is
called repeatedly for every comparison, tremendously slowing down the program.
(This was compiled with -O3.)
; This source compiled including the sqrt() function
; There are similar results for other sqrt functions
.L19:
mov eax, ebx
xor edx, edx
div r12d
testedx, edx; N % f == 0
je .L4 ; true, jump
movsd xmm1, QWORD PTR [rsp+8] ; false, continue loop
add r12d, 2 ; f += 2
.L5:
movapd xmm0, xmm1 ; Why do this block again?
movsd QWORD PTR [rsp+8], xmm1 ; N hasn't changed, and sqrt*
callsqrt; are pure functions.
pxorxmm2, xmm2 ; This makes the executable
cvttsd2si rax, xmm0 ; ~2x slower than gcc -O3's.
cmp r12d, eax
jbe .L19
You may have noticed the second optimization bug: the sqrt* call here isn't
optimized down to the processor's sqrt instruction. (These are sqrtsd for
sqrt() and sqrtss for sqrtf(). It doesn't look like there's an instruction for
sqrtl(), but if there is, LLVM should optimize to it.) Also note that there are
extraneous sqrt* calls/instructions in the full compiled output, for whatever
reasons LLVM's optimization engine has, but they're inconsistent. In the same
compiled output there are mixed function calls and instructions for the same
operation.
Some speed benchmarks for emphasis:
$ time ./primes-clangO3 => 0m5.298s real
Total primes: 664579
$ time ./primes-clangO0 => 0m5.701s "
Total primes: 644579
$ time ./primes-gccO3=> 0m2.872s "
Total primes: 664579
$ time ./primes-gccO0=> 0m5.703s "
Total primes: 664579
I hope there's an easy fix here.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24240 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_predication: Timeout in llvm-opt-fuzzer--x86_64-loop_predication
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-07-18 Type: Bug New issue 24240 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_predication: Timeout in llvm-opt-fuzzer--x86_64-loop_predication https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24240 Detailed Report: https://oss-fuzz.com/testcase?key=5967839618662400 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_predication Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 60 secs) Crash Address: Crash State: llvm-opt-fuzzer--x86_64-loop_predication Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5967839618662400 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46774] New: Crash on ternary op with _ExtInt and a different type
https://bugs.llvm.org/show_bug.cgi?id=46774
Bug ID: 46774
Summary: Crash on ternary op with _ExtInt and a different type
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ch3r...@openwall.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 23753
--> https://bugs.llvm.org/attachment.cgi?id=23753&action=edit
preprocessed source
clang segfaults on a ternary operator with mismatching types _ExtInt and int:
--
int main()
{
_ExtInt(2) x = 0;
0 ? x : 0;
}
--
$ clang test.c
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /home/user/cc/clang/bin/clang-11 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name test.c
-mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math
-mconstructor-aliases -munwind-tables -target-cpu x86-64
-fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir
/home/user/cc/clang/lib/clang/12.0.0 -internal-isystem /usr/local/include
-internal-isystem /home/user/cc/clang/lib/clang/12.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /home/user/c -ferror-limit 19 -fgnuc-version=4.2.1
-fcolor-diagnostics -faddrsig -o /tmp/test-e4a687.o -x c test.c
1. test.c:4:14: current parser token ';'
2. test.c:2:1: parsing function body 'main'
3. test.c:2:1: in compound statement ('{}')
#0 0x5644482743ba llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/user/cc/clang/bin/clang-11+0x1b693ba)
#1 0x564448272284 llvm::sys::RunSignalHandlers()
(/home/user/cc/clang/bin/clang-11+0x1b67284)
#2 0x5644482723b8 SignalHandler(int)
(/home/user/cc/clang/bin/clang-11+0x1b673b8)
#3 0x7f298f0eb730 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12730)
#4 0x564449e34287
clang::Sema::PrepareScalarCast(clang::ActionResult&,
clang::QualType) (/home/user/cc/clang/bin/clang-11+0x3729287)
#5 0x564449e6fb60
clang::Sema::CheckConditionalOperands(clang::ActionResult&,
clang::ActionResult&, clang::ActionResult&, clang::ExprValueKind&, clang::ExprObjectKind&, clang::SourceLocation)
(/home/user/cc/clang/bin/clang-11+0x3764b60)
#6 0x564449e700e8 clang::Sema::ActOnConditionalOp(clang::SourceLocation,
clang::SourceLocation, clang::Expr*, clang::Expr*, clang::Expr*)
(/home/user/cc/clang/bin/clang-11+0x37650e8)
#7 0x564449b546c7
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) (.localalias.318)
(/home/user/cc/clang/bin/clang-11+0x34496c7)
#8 0x564449b560e9
clang::Parser::ParseExpression(clang::Parser::TypeCastState)
(/home/user/cc/clang/bin/clang-11+0x344b0e9)
#9 0x564449ba229a
clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext)
(/home/user/cc/clang/bin/clang-11+0x349729a)
#10 0x564449ba309b
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&)
(/home/user/cc/clang/bin/clang-11+0x349809b)
#11 0x564449ba3e69
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*)
(/home/user/cc/clang/bin/clang-11+0x3498e69)
#12 0x564449ba7c21 clang::Parser::ParseCompoundStatementBody(bool)
(/home/user/cc/clang/bin/clang-11+0x349cc21)
#13 0x564449baab93 clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) (/home/user/cc/clang/bin/clang-11+0x349fb93)
#14 0x564449b0fc02
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)
(/home/user/cc/clang/bin/clang-11+0x3404c02)
#15 0x564449b37f36 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/home/user/cc/clang/bin/clang-11+0x342cf36)
#16 0x564449b0b091
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
(/home/user/cc/clang/bin/clang-11+0x3400091)
#17 0x564449b0b6c1
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.266)
(/home/user/cc/clang/bin/clang-11+0x34006c1)
#18 0x564449b11a10
clang::Parser::ParseExternalDeclar
[llvm-bugs] [Bug 38180] For programs which fork, some lines are wrongly considered as hit twice
https://bugs.llvm.org/show_bug.cgi?id=38180 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@maskray.me Resolution|--- |FIXED --- Comment #2 from Fangrui Song --- https://reviews.llvm.org/D53593 I fixed the test in ca1cc5c4e067d496e92e775bd0ac30c1b775bb62 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38402] Support collecting coverage for static destructors
https://bugs.llvm.org/show_bug.cgi?id=38402 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |i...@maskray.me CC||i...@maskray.me Status|NEW |RESOLVED --- Comment #1 from Fangrui Song --- Fixed by https://reviews.llvm.org/D82253 (will be available in llvm 11) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38064] writeout and flush functions are redundant
https://bugs.llvm.org/show_bug.cgi?id=38064 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |i...@maskray.me CC||i...@maskray.me Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- Fixed by https://reviews.llvm.org/D83149 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
