[llvm-bugs] [Bug 45895] New: Wrong Line Information at O1
https://bugs.llvm.org/show_bug.cgi?id=45895
Bug ID: 45895
Summary: Wrong Line Information at O1
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: massare...@diag.uniroma1.it
CC: blitzrak...@gmail.com, dgre...@apple.com,
ditali...@apple.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Line 9 should not be hit during debugging.
$ cat a.c
char a;
int b;
void c(d)
{
int si1 = a, si2 = d;
b =
si1 > si2 || si2 > si1 < si2 ?
0 :
si1 * si2;
}
int main ()
{
c(80);
}
$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
c25b20c0f6c13d68dbc2e185764082d61ae4a132)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0
Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ lldb -v
lldb version 11.0.0
clang revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
llvm revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
$ clang -O1 -g -o opt a.c
$ lldb opt
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b -l 9
Breakpoint 1: where = opt`c + 19 at a.c:9:15, address = 0x004004b3
(lldb) r
Process 229 launched: 'opt' (x86_64)
Process 229 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x004004b3 opt`c(d=80) at a.c:9:15
6b =
7 si1 > si2 || si2 > si1 < si2 ?
8 0 :
-> 9 si1 * si2;
10 }
11 int main ()
12 {
(lldb) p si1
(int) $0 = 0
(lldb) p si2
(int) $1 = 80
(lldb) expr si1 > si2 || si2 > si1 < si2
(bool) $2 = true
(lldb) s
Process 229 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004b8 opt`c(d=80) at a.c:7:34
4{
5 int si1 = a, si2 = d;
6b =
-> 7 si1 > si2 || si2 > si1 < si2 ?
8 0 :
9 si1 * si2;
10 }
(lldb) s
Process 229 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004bd opt`c(d=80) at a.c:6:11
3void c(d)
4{
5 int si1 = a, si2 = d;
-> 6b =
7 si1 > si2 || si2 > si1 < si2 ?
8 0 :
9 si1 * si2;
(lldb) s
Process 229 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004c3 opt`c(d=80) at a.c:10:5
7 si1 > si2 || si2 > si1 < si2 ?
8 0 :
9 si1 * si2;
-> 10 }
11 int main ()
12 {
13 c(80);
(lldb) s
Process 229 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004db opt`main at a.c:14:5
11 int main ()
12 {
13 c(80);
-> 14 }
(lldb) s
--
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 45896] New: clang creates a symbol it cannot demangle
https://bugs.llvm.org/show_bug.cgi?id=45896 Bug ID: 45896 Summary: clang creates a symbol it cannot demangle Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 23477 --> https://bugs.llvm.org/attachment.cgi?id=23477&action=edit reproducer bin/clang++ -m64 -march=x86-64 -c a.ii -o /tmp/a.o -w && nm /tmp/a.o | grep _ZN21hb_sanitize_context_t9_dispatchIN2OT14VariationStoreEJEEEDTcldtfp_8sanitizefpTspcl1nIT0_Efp1_EEERKT_11hb_priorityILj1EEDpOS3_ U _ZN21hb_sanitize_context_t9_dispatchIN2OT14VariationStoreEJEEEDTcldtfp_8sanitizefpTspcl1nIT0_Efp1_EEERKT_11hb_priorityILj1EEDpOS3_ llvm-cxxfilt is not able to demangle this. -- 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 45897] New: [X86][SSE] Improve combining to ISD::MULHS/MULHU
https://bugs.llvm.org/show_bug.cgi?id=45897
Bug ID: 45897
Summary: [X86][SSE] Improve combining to ISD::MULHS/MULHU
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
This is a general bug/brain dump to cover a few areas that we might want to
consider to encourage use of the vXi16 ISD::MULHS/MULHU opcodes where possible
as they can give notable perf improvements over vXi32 multiples.
1 - Move the PPC combines from https://reviews.llvm.org/D78272 into DAGCombiner
if x86 can benefit as well.
2 - X86ISelLowering.cpp - combinePMULH currently performs:
vXi16 trunc(srl(mul({sz}ext(x),{sz}ext(y)),16)) -> vXi16 mulh{sz}(x,y)
But it might be beneficial to combine any x/y with sufficient leading sign/zero
bits - it depends on how cheap the truncation will be (PACKS/VTRUNC/nop/???)
compared to the penalty of the wider multiply/shift:
vXi16 trunc(srl(mul(x,y),16)) -> vXi16 mulh{sz}(trunc(x),trunc(y))
3 - Try to perform more truncation style combines even after combining to
PACKS/VTRUNC ops. We can probably still see the truncation pattern behind the
op, so maybe a SelectionDAG::simplifyTrunc() would be useful or a x86-only
combineTruncLike? Or at the very least try to match the SimplifyDemandedBits
calls we have for ISD::TRUNCATE.
4 - See if [Bug #38423] would still be useful - does
SimplifyDemandedBits/shuffle combining always simplify the vXi64 mul expansion
for us?
--
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 45898] New: Failure to combine rotate through a select
https://bugs.llvm.org/show_bug.cgi?id=45898
Bug ID: 45898
Summary: Failure to combine rotate through a select
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
Not sure whether this can be done in instcombine or must wait until DAG.
https://c.godbolt.org/z/Pam6xk
#include
uint8_t rotl_2(uint8_t x) {
uint8_t Xlo = (x<<2);
uint8_t Xhi = (x>>6);
uint8_t Xrot = Xlo|Xhi;
return (x < 128 ? Xrot : Xlo);
}
we have a conditional use of a rotate pattern, which unfortunately gets broken
up by the select
define zeroext i8 @rotl_2(i8 zeroext %0) {
%2 = shl i8 %0, 2
%3 = lshr i8 %0, 6
%4 = icmp slt i8 %0, 0
%5 = select i1 %4, i8 0, i8 %3
%6 = or i8 %5, %2
ret i8 %6
}
resulting in:
rotl_2:
leal(,%rdi,4), %ecx
movl%edi, %eax
shrb$6, %al
xorl%edx, %edx
testb %dil, %dil
movzbl %al, %eax
cmovsl %edx, %eax
orb %cl, %al
retq
while gcc manages:
rotl_2:
movl%edi, %edx
leal0(,%rdi,4), %eax
rolb$2, %dl
testb %dil, %dil
cmovns %edx, %eax
ret
--
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 33705] False positive with two identical conditionals
https://bugs.llvm.org/show_bug.cgi?id=33705 Denys Petrov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Denys Petrov --- coypu Seems we can mark it as resolved one. -- 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 45830] [AMDGPU][MC][GFX9+] Instructions v_add_i32 and v_sub_i32 do not support clamp modifier
https://bugs.llvm.org/show_bug.cgi?id=45830 Dmitry changed: What|Removed |Added Fixed By Commit(s)||18a5428 Resolution|--- |FIXED Status|NEW |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 45709, which changed state. Bug 45709 Summary: misoptimization with defaulting to POWER7 and newer https://bugs.llvm.org/show_bug.cgi?id=45709 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45709] misoptimization with defaulting to POWER7 and newer
https://bugs.llvm.org/show_bug.cgi?id=45709 Nemanja Ivanovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Nemanja Ivanovic --- Fix in https://reviews.llvm.org/D79854 -- 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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 45709, which changed state. Bug 45709 Summary: misoptimization with defaulting to POWER7 and newer https://bugs.llvm.org/show_bug.cgi?id=45709 What|Removed |Added Status|RESOLVED|REOPENED Resolution|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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45709] misoptimization with defaulting to POWER7 and newer
https://bugs.llvm.org/show_bug.cgi?id=45709 Nemanja Ivanovic changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #19 from Nemanja Ivanovic --- Meant to select "Confirmed" rather than "Resolved" since the patch is just posted for review, not committed yet. -- 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 45899] New: LLParser fails due to the "non-global-value-max-name-size" limit in Value.cpp
https://bugs.llvm.org/show_bug.cgi?id=45899
Bug ID: 45899
Summary: LLParser fails due to the
"non-global-value-max-name-size" limit in Value.cpp
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM assembly language parser
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 23478
--> https://bugs.llvm.org/attachment.cgi?id=23478&action=edit
bbi-42804.ll reproducer
Reproduce with:
opt -S -o - bbi-42804.ll
which gives
build-all-builtins/bin/opt: bbi-42804.ll:7:12: error: use of undefined value
'%for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit_edge.i.split.split.split_crit_edge.i.split.split.for.body4.lr.ph.split.split.split.us18.split.split.for.body4.lr.ph.split.split.split.us18.split.split.split_crit7'
but the value it complains on is indeed defined in the input file.
If we instead do
opt -S -o - bbi-42804.ll -non-global-value-max-name-size=1025
there is no error.
I don't know how things are supposed to work with the
"non-global-value-max-name-size" name limiit, but I think there is some
mismatch right now, where the LLParser doesn't consider that limit when it does
lookups in the symbol table in e.g LLParser::PerFunctionState::GetVal:
Value *LLParser::PerFunctionState::GetVal(const std::string &Name, Type *Ty,
LocTy Loc, bool IsCall) {
// Look this name up in the normal function symbol table.
Value *Val = F.getValueSymbolTable()->lookup(Name);
// If this is a forward reference for the value, see if we already created a
// forward ref record.
if (!Val) {
auto I = ForwardRefVals.find(Name);
if (I != ForwardRefVals.end())
Val = I->second.first;
}
// If we have the value in the symbol table or fwd-ref table, return it.
if (Val)
return P.checkValidVariableType(Loc, "%" + Name, Ty, Val, IsCall);
// Don't make placeholders with invalid type.
if (!Ty->isFirstClassType()) {
P.Error(Loc, "invalid use of a non-first-class type");
return nullptr;
}
// Otherwise, create a new forward reference for this value and remember it.
Value *FwdVal;
if (Ty->isLabelTy()) {
FwdVal = BasicBlock::Create(F.getContext(), Name, &F);
} else {
FwdVal = new Argument(Ty, Name);
}
"Name" above is not truncated, so the
Value *Val = F.getValueSymbolTable()->lookup(Name);
lookup tries to find the full name which fails even if it really shouldn't.
Then we create a new BasicBlock:
FwdVal = BasicBlock::Create(F.getContext(), Name, &F);
but there it will be a collision in the symboltable so we use
ValueSymbolTable::makeUniqueName which will add a unique number to the end of
the name and then we get some mismatch where someone thinks we're jumping to a
basic block that doesn't exist.
--
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 45900] New: internal error with symbol defined from C and asm
https://bugs.llvm.org/show_bug.cgi?id=45900
Bug ID: 45900
Summary: internal error with symbol defined from C and asm
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: a...@linaro.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
This trivial (invalid) source causes an internal error with the integrated
assembler (see also https://godbolt.org/z/9JoX9S):
int sym; asm("sym:");
fatal error: error in backend: symbol 'sym' is already defined
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: /opt/compiler-explorer/clang-trunk/bin/clang -g -o
./output.s -S --gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0
-fcolor-diagnostics -fno-crash-diagnostics
1. parser at end of file
2. Code generation
#0 0x562ae993414a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2bce14a)
#1 0x562ae9931f14 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2bcbf14)
#2 0x562ae9932185 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2bcc185)
#3 0x562ae98aa972 llvm::CrashRecoveryContext::HandleExit(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2b44972)
#4 0x562ae992b0d7 llvm::sys::Process::Exit(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2bc50d7)
#5 0x562ae7b919d1 LLVMErrorHandler(void*, std::__cxx11::basic_string, std::allocator > const&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+0xe2b9d1)
#6 0x562ae98b0ef1 llvm::report_fatal_error(llvm::Twine const&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2b4aef1)
#7 0x562aea39e703
llvm::AsmPrinter::emitGlobalVariable(llvm::GlobalVariable const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x3638703)
#8 0x562aea399d9a llvm::AsmPrinter::doFinalization(llvm::Module&)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x3633d9a)
#9 0x562ae9283e0c llvm::FPPassManager::doFinalization(llvm::Module&)
(.localalias.512) (/opt/compiler-explorer/clang-trunk/bin/clang+0x251de0c)
#10 0x562ae9290270 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x252a270)
#11 0x562ae9ba9828 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr >)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2e43828)
#12 0x562ae9bab3ea clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2e453ea)
#13 0x562aea6d1abc
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x396babc)
#14 0x562aeb3cf269 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x4669269)
#15 0x562aea107839 clang::FrontendAction::Execute()
(/opt/compiler-explorer/clang-trunk/bin/clang+0x33a1839)
#16 0x562aea0c2b03
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x335cb03)
#17 0x562aea1cbd4b
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x3465d4b)
#18 0x562ae7b92e8c cc1_main(llvm::ArrayRef, char const*,
void*) (/opt/compiler-explorer/clang-trunk/bin/clang+0xe2ce8c)
#19 0x562ae7b8fabd ExecuteCC1Tool(llvm::SmallVectorImpl&)
(/opt/compiler-explorer/clang-trunk/bin/clang+0xe29abd)
#20 0x562ae9f9d455 void llvm::function_ref::callback_fn
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const::'lambda'()>(long)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x3237455)
#21 0x562ae98aa803
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x2b44803)
#22 0x562ae9f9e0c0
clang::driver::CC1Command::Execute(llvm::ArrayRef
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const (.part.152)
(/opt/compiler-explorer/clang-trunk/bin/clang+0x32380c0)
#23 0x562ae9f788c5
clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&,
clang::driver::Command const*&) const
(/opt/compiler-explorer/clang-trunk/bin/clang+0x32128c5)
#24 0x562ae9f7930f
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&,
llvm::SmallVectorImpl >&) const
(/opt/compiler-explorer/clang-trunk/bin/clang+0x321330f)
#25 0x562ae
[llvm-bugs] [Bug 45901] New: clang shall not pass --hash-style to the linker
https://bugs.llvm.org/show_bug.cgi?id=45901 Bug ID: 45901 Summary: clang shall not pass --hash-style to the linker Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dilyan.palau...@aegee.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk I compile binutils with ./configure --enable-default-hash-style=gnu . I compile gcc with ./configure --with-linker-hash-style=gnu. So when I call gcc, or just ld.bfd, or ld.gold I get no sysv hashes. When I call `clang -v` I see that it passes to the linker --hash-style=both . During the configuration (before the build) of clang I see no option to set the default hash style. • Add a CMAKE option to set the default hash style, when calling the linker, with default of not sending --hash-style= to the linker • Do not pass -hash-style= when calling the linker, unless explicitly told to do 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45902] New: Wrong Debug Information at O3
https://bugs.llvm.org/show_bug.cgi?id=45902
Bug ID: 45902
Summary: Wrong Debug Information at O3
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: massare...@diag.uniroma1.it
CC: ditali...@apple.com, jdevliegh...@apple.com,
llvm-bugs@lists.llvm.org
Debug information seems wrong at O3.
At line 7 variable j and k should not be visible.
$ cat a.c
int a[56];
int b ;
int c[1] ;
int d[1][9][8] ;
void
e (f) {
b =
b & 5 ^
a[b ^ f ];
}
void h (f) {
long g = f;
{
b = b & 5 ^ a[b ];
b = b & 5 ^ a[b ^ 8 ];
b = b & 5 ^ a[b ^ g ];
b = b & 5 ^ a[b ^ g ];
}
e (g & 5);
e (g>>48 & 5);
e (g>>56 & 5);
}
int main ()
{
int i, j, k, dm ;
{
d[0][1][0] = 0;
}
printf("ciao");
h(0);
j = 0;
for (; j < 9; j++)
{
k = 0;
for (; k < 8; k++)
h(d[0][j][k]);
}
}
$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
c25b20c0f6c13d68dbc2e185764082d61ae4a132)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0
Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ lldb -v
lldb version 11.0.0
clang revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
llvm revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
$ clang -O3 -g -o opt a.c
$ lldb opt
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b -l 7
Breakpoint 1: 3 locations.
(lldb) r
Process 60 launched: 'opt' (x86_64)
Process 60 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.3
frame #0: 0x00400618 opt`main [inlined] e(f=0) at a.c:7:4
4int d[1][9][8] ;
5void
6e (f) {
-> 7 b =
8 b & 5 ^
9 a[b ^ f ];
10 }
(lldb) frame var
(int) f = 0
(lldb) s
Process 60 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x0040061e opt`main at a.c:7:4
4int d[1][9][8] ;
5void
6e (f) {
-> 7 b =
8 b & 5 ^
9 a[b ^ f ];
10 }
(lldb) frame var
(int) j = 0
(int) k = 0
(int) i =
(int) dm =
(lldb)
$ gdb opt
Breakpoint 1, e (f=0) at a.c:7
7b =
(gdb) frame var
#0 e (f=0) at a.c:7
7b =
(gdb) bt
#0 e (f=0) at a.c:7
#1 h (f=0) at a.c:22
#2 main () at a.c:32
(gdb) s
main () at a.c:38
38 h(d[0][j][k]);
(gdb) frame var
#0 main () at a.c:38
38 h(d[0][j][k]);
(gdb) c
Continuing.
ciao[Inferior 1 (process 153) exited normally]
(gdb)
--
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 41509] wrong code after running structurizecfg pass
https://bugs.llvm.org/show_bug.cgi?id=41509 Ehud Katz changed: What|Removed |Added Fixed By Commit(s)||rG897d8ee5cd69 Status|CONFIRMED |RESOLVED Resolution|--- |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45903] New: overrestrictive asm goto gotolabels limitations
https://bugs.llvm.org/show_bug.cgi?id=45903
Bug ID: 45903
Summary: overrestrictive asm goto gotolabels limitations
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: ja...@shuf.ro
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
First of all, I apologize if this is the wrong venue for this bug report.
The following does not compile, even though I believe it should:
---
cleanup_cb(*p1) {}
foo(int n) {
int cond;
if (({
asm goto("" ::"r"(cond) : : label0);
1;
}))
label0:;
int a[n];
if (({
asm goto("" ::"r"(cond) : : label1);
1;
}))
label1:;
}
main() {}
---
jshufro@660:~/asmgoto$ clang-10 main.c
main.c:1:13: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
cleanup_cb(*p1) {}
^
main.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
cleanup_cb(*p1) {}
^
main.c:1:18: warning: non-void function does not return a value [-Wreturn-type]
cleanup_cb(*p1) {}
^
main.c:3:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
foo(int n) {
^
main.c:7:9: error: cannot jump from this asm goto statement to one of its
possible targets
asm goto("" ::"r"(cond) : : label0);
^
main.c:18:3: note: possible target of asm goto statement
label1:;
^
main.c:12:7: note: jump bypasses initialization of variable length array
int a[n];
^
main.c:22:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
main() {}
^
5 warnings and 1 error generated.
---
This is C-Reduced to be fairly minimal. Replacing the variable length array
with an __attribute__((cleanup)) variable causes a similar issue. It's worth
noting that the error is noting a possible target of asm goto that isn't listed
in the GoToLabels.
--
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 45904] New: Fulfilling event inside task causes deadlock
https://bugs.llvm.org/show_bug.cgi?id=45904 Bug ID: 45904 Summary: Fulfilling event inside task causes deadlock Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: schuch...@hlrs.de CC: llvm-bugs@lists.llvm.org Created attachment 23479 --> https://bugs.llvm.org/attachment.cgi?id=23479&action=edit Minimal example A task with the detach clause is not completed if the event is fulfilled inside the task itself before its execution terminates. Attached is a minimal example (provided by Joachim Protze) to demonstrate this. The execution deadlocks with the task waiting in the taskwait construct: #0 0x778ccd15 in __kmp_remove_my_task (thread=0x624600, gtid=0, task_team=0x6278c0, is_constrained=1) at openmp/runtime/src/kmp_tasking.cpp:2588 #1 0x778d3131 in __kmp_execute_tasks_template (thread=0x624600, gtid=0, flag=0x7fffd260, final_spin=0, thread_finished=0x7fffd28c, itt_sync_obj=0x0, is_constrained=1) at openmp/runtime/src/kmp_tasking.cpp:2827 #2 0x778cd6c3 in __kmp_execute_tasks_32 (thread=0x624600, gtid=0, flag=0x7fffd260, final_spin=0, thread_finished=0x7fffd28c, itt_sync_obj=0x0, is_constrained=1) at openmp/runtime/src/kmp_tasking.cpp:3002 #3 0x778d4772 in kmp_flag_32::execute_tasks (this=0x7fffd260, this_thr=0x624600, gtid=0, final_spin=0, thread_finished=0x7fffd28c, itt_sync_obj=0x0, is_constrained=1) at openmp/runtime/src/kmp_wait_release.h:753 #4 0x778d2ed7 in __kmpc_omp_taskwait_template (loc_ref=0x7fffd328, gtid=0, frame_address=0x0, return_address=0x0) at openmp/runtime/src/kmp_tasking.cpp:1863 #5 0x778cb8e9 in __kmpc_omp_taskwait (loc_ref=0x7fffd328, gtid=0) at openmp/runtime/src/kmp_tasking.cpp:1923 #6 0x004009e9 in .omp_outlined._debug__ (.global_tid.=0x7fffd390, .bound_tid.=0x7fffd388) at test_omp_detach_taskwait.c:13 #7 0x00400abd in .omp_outlined..1 (.global_tid.=0x7fffd390, .bound_tid.=0x7fffd388) at test_omp_detach_taskwait.c:5 #8 0x7793c113 in __kmp_invoke_microtask () at openmp/runtime/src/z_Linux_asm.S:1166 #9 0x778a4fb0 in __kmp_fork_call (loc=0x7fffd740, gtid=0, call_context=fork_context_intel, argc=0, microtask=0x400aa0 <.omp_outlined..1>, invoker=0x778b13ad <__kmp_invoke_task_func(int)>, ap=0x7fffd628) at openmp/runtime/src/kmp_runtime.cpp:1887 #10 0x77892890 in __kmpc_fork_call (loc=0x7fffd740, argc=0, microtask=0x400aa0 <.omp_outlined..1>) at openmp/runtime/src/kmp_csupport.cpp:308 #11 0x004008cb in main () at test_omp_detach_taskwait.c:5 Clang and libomp were built from git-72edb7986a8059cda12b808aa68828af88a0a1eb -- 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 45905] New: [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end())
https://bugs.llvm.org/show_bug.cgi?id=45905 Bug ID: 45905 Summary: [lldb][unittest] Assertion failed : (m_replayers.find(RunID) == m_replayers.end()) Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: sylvain.a...@ubisoft.com CC: alexandre.ga...@ubisoft.com, jdevliegh...@apple.com, llvm-bugs@lists.llvm.org This happens in the LLDB unit tests, when building under windows. In lldb\unittests\Utility\ReproducerInstrumentationTest.cpp: LLDB_REGISTER_METHOD(void, InstrumentedFoo, Validate, ()); (...) LLDB_REGISTER_METHOD(void, InstrumentedBar, Validate, ()); The clashing IDs are evaluated as follows: &invoke::method<(&InstrumentedFoo::Validate)>::record and &invoke::method<(&InstrumentedBar::Validate)>::record Both "record" implementations are only calling Validate() through the vtable, so the implementations are identical for both. The linker does COMDAT folding (option /OPT:ICF), which merges the 2 functions, so their address, which is used as an ID, end up being identical. -- 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 45906] New: Cannot emit physreg copy instruction: cannot copy ZMM4 to RDI
https://bugs.llvm.org/show_bug.cgi?id=45906 Bug ID: 45906 Summary: Cannot emit physreg copy instruction: cannot copy ZMM4 to RDI Product: libraries Version: 9.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: vtjn...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 23480 --> https://bugs.llvm.org/attachment.cgi?id=23480&action=edit input function >From analysis of https://github.com/JuliaLang/julia/issues/35393, caused by some slightly confused combination of TargetMachine and optimization level options. We saw that the attached ll file generates the attached mir file, which fails inside llvm::X86InstrInfo::copyPhysReg. Seems it should be dead code as I don't see a use of the value, but due to incomplete coverage of register sizes it's causing a crash on: renamable $rdi = COPY killed renamable $zmm4 -- 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 45907] New: c++2a mode failures compiling LLVM Verifier.h - == overloads !=?
https://bugs.llvm.org/show_bug.cgi?id=45907
Bug ID: 45907
Summary: c++2a mode failures compiling LLVM Verifier.h - ==
overloads !=?
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: llvm-b...@bleg.org
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Raised as release blocker because this appears to be a regression.
It seems that operator== and operator!= are judged to be ambiguous overloads in
c++2a mode only (new in clang 10).
/usr/include/llvm/ADT/DenseMap.h:1222:8: note: candidate function
bool operator!=(const ConstIterator &RHS) const {
^
/usr/include/llvm/ADT/DenseMap.h:1215:8: note: candidate function
bool operator==(const ConstIterator &RHS) const {
$ uname -a
Linux flaky 5.4.0-29-generic #33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 2020 x86_64
x86_64 x86_64 GNU/Linux
$ clang++-10 -v
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat verifier.cpp
#include
int main() {
return 0;
}
$ clang++-10 -c verifier.cpp
$ clang++-9 -c -std=c++2a verifier.cpp
$ clang++-10 -c -std=c++2a verifier.cpp
In file included from verifier.cpp:1:
In file included from /usr/include/llvm/IR/Verifier.h:24:
/usr/include/llvm/IR/PassManager.h:694:17: error: use of overloaded operator
'!=' is ambiguous (with operand types 'llvm::DenseMapIterator,
llvm::detail::DenseMapPair, false>' and
'llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::AnalysisKey *,
bool, llvm::DenseMapInfo,
llvm::detail::DenseMapPair >::iterator' (aka
'DenseMapIterator,
llvm::detail::DenseMapPair >'))
if (IMapI != IsResultInvalidated.end())
~ ^ ~
/usr/include/llvm/ADT/DenseMap.h:1222:8: note: candidate function
bool operator!=(const ConstIterator &RHS) const {
^
/usr/include/llvm/ADT/DenseMap.h:1215:8: note: candidate function
bool operator==(const ConstIterator &RHS) const {
^
/usr/include/llvm/ADT/DenseMap.h:1215:8: note: candidate function (with
reversed parameter order)
...
--
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 45909] New: libraries in libomp-*-dev package not in LD_LIBRARY_PATH
https://bugs.llvm.org/show_bug.cgi?id=45909 Bug ID: 45909 Summary: libraries in libomp-*-dev package not in LD_LIBRARY_PATH Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: steffen.seck...@tum.de CC: llvm-bugs@lists.llvm.org Hi, I have noticed that the libraries provided by the libomp-*-dev (e.g. libomp-11-dev) packages are not in the LD_LIBRARY_PATH and thus cannot be found by dlopen. I would have expected these to either be placed somewhere they can be found or that the LD_LIBRARY_PATH is modified. This mainly affects the dynamic loading of these libraries, e.g., libarcher.so through TSan. System: ubuntu 20.04 Repositories: deb http://apt.llvm.org/focal/ llvm-toolchain-focal main deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal main Thanks in advance! -- 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 45910] New: [ARM] Merge fc373522b044 into 10.0.1
https://bugs.llvm.org/show_bug.cgi?id=45910 Bug ID: 45910 Summary: [ARM] Merge fc373522b044 into 10.0.1 Product: new-bugs Version: 10.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dimi...@andric.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Please merge https://reviews.llvm.org/rGfc373522b044 into 10.0.1. This is a follow-up for big-endian ARM of https://reviews.llvm.org/rG2e24219d3cbf, which fixed bug 44929 (and was already merged into 10.0.0 via https://reviews.llvm.org/rG058a8cd73f33): Author: Dimitry Andric Date: 2020-05-12T19:27:48+02:00 New Revision: fc373522b044e0b150561204958f0d603fb4caba URL: https://github.com/llvm/llvm-project/commit/fc373522b044e0b150561204958f0d603fb4caba DIFF: https://github.com/llvm/llvm-project/commit/fc373522b044e0b150561204958f0d603fb4caba.diff LOG: [arm] Add big-endian version of pcrel fixups for adr instructions Summary: In 2e24219d3cbf, a number of ARM pcrel fixups were resolved at assembly time, to solve PR44929. This only covered little-endian ARM however, so add similar fixups for big-endian ARM. Also extend the test case to cover big-endian ARM. Reviewers: hans, psmith, MaskRay Reviewed By: psmith, MaskRay Subscribers: kristof.beyls, hiraditya, danielkiss, emaste, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79774 -- 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 45911] New: Data sharing and lambda capture: No context value for inlined OpenMP region
https://bugs.llvm.org/show_bug.cgi?id=45911 Bug ID: 45911 Summary: Data sharing and lambda capture: No context value for inlined OpenMP region Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: schuch...@hlrs.de CC: llvm-bugs@lists.llvm.org Created attachment 23484 --> https://bugs.llvm.org/attachment.cgi?id=23484&action=edit Reproducer cpp file I came across the following error when I accidentally left a variable undefined inside a lambda, which was defined outside the lambda. The source file is attached to this issue. No context value for inlined OpenMP region UNREACHABLE executed at llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:247! 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: clang++ -c -fopenmp -fopenmp-version=50 test_omp_lambda.cc -o test_omp_lambda 1. parser at end of file 2. Per-file LLVM IR generation 3. test_omp_lambda.cc:22:7: Generating code for declaration 'main()::(anonymous class)::operator()' #0 0x02b4e21a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (clang-11+0x2b4e21a) #1 0x02b4c114 llvm::sys::RunSignalHandlers() (clang-11+0x2b4c114) #2 0x02b4c355 llvm::sys::CleanupOnSignal(unsigned long) (clang-11+0x2b4c355) #3 0x02ac5868 CrashRecoverySignalHandler(int) (clang-11+0x2ac5868) #4 0x7f3d29695630 __restore_rt (/lib64/libpthread.so.0+0xf630) #5 0x7f3d28207387 raise (/lib64/libc.so.6+0x36387) #6 0x7f3d28208a78 abort (/lib64/libc.so.6+0x37a78) #7 0x02acd09a (clang-11+0x2acd09a) #8 0x030e294e (clang-11+0x30e294e) #9 0x03044f3e clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*) (clang-11+0x3044f3e) #10 0x0304326e clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) (clang-11+0x304326e) #11 0x03121317 emitPrivatesInit(clang::CodeGen::CodeGenFunction&, clang::OMPExecutableDirective const&, clang::CodeGen::Address, clang::CodeGen::LValue, clang::RecordDecl const*, clang::QualType, clang::QualType, clang::CodeGen::OMPTaskDataTy const&, llvm::ArrayRef >, bool) (clang-11+0x3121317) #12 0x03122fbb clang::CodeGen::CGOpenMPRuntime::emitTaskInit(clang::CodeGen::CodeGenFunction&, clang::SourceLocation, clang::OMPExecutableDirective const&, llvm::Function*, clang::QualType, clang::CodeGen::Address, clang::CodeGen::OMPTaskDataTy const&) (clang-11+0x3122fbb) #13 0x031244e7 clang::CodeGen::CGOpenMPRuntime::emitTaskCall(clang::CodeGen::CodeGenFunction&, clang::SourceLocation, clang::OMPExecutableDirective const&, llvm::Function*, clang::QualType, clang::CodeGen::Address, clang::Expr const*, clang::CodeGen::OMPTaskDataTy const&) (clang-11+0x31244e7) #14 0x02df782c void llvm::function_ref::callback_fn(long, clang::CodeGen::CodeGenFunction&, llvm::Function*, clang::CodeGen::OMPTaskDataTy const&) (clang-11+0x2df782c) #15 0x02e23eee clang::CodeGen::CodeGenFunction::EmitOMPTaskBasedDirective(clang::OMPExecutableDirective const&, llvm::omp::Directive, clang::CodeGen::RegionCodeGenTy const&, llvm::function_ref const&, clang::CodeGen::OMPTaskDataTy&) (clang-11+0x2e23eee) #16 0x02e244c2 clang::CodeGen::CodeGenFunction::EmitOMPTaskDirective(clang::OMPTaskDirective const&) (clang-11+0x2e244c2) #17 0x02df2eed clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef) (clang-11+0x2df2eed) #18 0x02df315c clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (clang-11+0x2df315c) #19 0x02e33147 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (clang-11+0x2e33147) #20 0x02e418d5 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (clang-11+0x2e418d5) #21 0x02e790a5 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (clang-11+0x2e790a5) #22 0x02e76b55 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (clang-11+0x2e76b55) #23 0x02e7d9df clang::CodeGen::CodeGenModule::EmitDeferred() (clang-11+0x2e7d9df) #24 0x02e7da0b clang::CodeGen::CodeGenModule::EmitDeferred() (clang-11+0x2e7da0b) #25 0x02e7da0b clang::CodeGen::CodeGenModule::EmitDeferred() (clang-11+0x2e7da0b) #26 0x02e7db59 clang::CodeGen::CodeGenModule::Release() (clang-11+0x2e7db59) #27 0x038c6857 (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&) (clang-11+0x38c685
[llvm-bugs] [Bug 45890] alignof(reference_to_type) doesn't return alignof(referenced_type) as it should by the standard
https://bugs.llvm.org/show_bug.cgi?id=45890 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |LATER --- Comment #2 from Richard Smith --- Given that we currently implement this as a GCC extension, and our current behaviour is consistent with that of GCC, we should not take any action on this until / unless an alternative rule is standardized or GCC's behaviour changes. Please reopen if and when that happens. -- 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 45912] New: Call to consteval function isn't folded to a constant
https://bugs.llvm.org/show_bug.cgi?id=45912
Bug ID: 45912
Summary: Call to consteval function isn't folded to a constant
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: ldio...@apple.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
The following program calling a consteval function causes code to be emitted to
compute the result of maxFoo() at runtime, when one would expect it to be
computed at compile-time:
$ cat <
#include
struct Foo { int i; };
static constexpr std::array foos = {{{1}, {2}, {3}}};
static int consteval maxFoo() {
auto it = std::max_element(foos.begin(), foos.end(), [](auto lhs, auto
rhs) {
return lhs.i < rhs.i;
});
return it->i;
}
int main() { return maxFoo(); }
EOF
Here's a few interesting observations:
1. This only happens when -Os or -O1 are used.
2. Even slight modifications of the above code will cause it to be inlined, for
example implementing `maxFoo()` equivalently but in a single expression.
3. The same issue happens whether `consteval` is used or not (which leads me to
think this is a codegen issue, not a front-end issue).
Godbolt link: https://godbolt.org/z/MA9U8b
After playing around and debugging Clang for a bit, I am fairly confident that
this is not a bug per-se, but only an important QOI issue. In particular, I
think Clang behaves correctly with respect to the Standard, which only says
about immediate functions (http://eel.is/c++draft/expr.const#13):
> [...] An expression or conversion is an immediate invocation if
> it is a potentially-evaluated explicit or implicit invocation of
> an immediate function and is not in an immediate function context.
> An immediate invocation shall be a constant expression.
This doesn't talk about codegen, since the Standard doesn't have such a notion.
Also, Clang does treat `maxFoo()` as a constant expression, and in fact the
front-end even calculates the result properly in an APValue -- so Clang is
*correct* as far as the Standard is concerned.
However, the code generation appears to never be passed that knowledge, and as
a result it can sometimes fail to fold the immediate call, depending on
optimization levels. Since the intent of consteval was *specifically* to make
sure that no code is generated for such calls, I would argue this is an
important QOI issue (if we're being pedantic), and straight up a bug (as far as
99% of users are concerned).
--
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 45913] New: LLD should not error out on "-plugin-opt=Os"
https://bugs.llvm.org/show_bug.cgi?id=45913 Bug ID: 45913 Summary: LLD should not error out on "-plugin-opt=Os" Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: manojgu...@google.com CC: george.burgess...@gmail.com, llvm-bugs@lists.llvm.org, mask...@google.com, smithp...@googlemail.com (Also see https://bugs.chromium.org/p/chromium/issues/detail?id=1082378) Clang passes "-plugin-opt=Os" to LLD when "-Os" is passed to clang in lto or thnlto mode. LLD however does not like it. $ clang -o main foo.o -Os -flto=thin -fuse-ld=lld -v ld.lld: error: -plugin-opt=Os: number expected, but got 's' clang-11: error: linker command failed with exit code 1 (use -v to see invocation) "-Os" is a fairly common compiler option and may not be easy to remove from build flags. It'd be nice if LLD does not error out in this case. -- 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 45907] c++2a mode failures compiling LLVM Verifier.h - == overloads !=?
https://bugs.llvm.org/show_bug.cgi?id=45907 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Smith --- *** This bug has been marked as a duplicate of bug 43765 *** -- 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 45913] LLD should not error out on "-plugin-opt=Os"
https://bugs.llvm.org/show_bug.cgi?id=45913 Fangrui Song changed: What|Removed |Added Resolution|--- |DUPLICATE CC||i...@maskray.me Status|NEW |RESOLVED --- Comment #1 from Fangrui Song --- I'll ask LTO people what we should do :) *** This bug has been marked as a duplicate of bug 42445 *** -- 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 45914] New: Using "long double" as asm register in x86_64 crashes llc
https://bugs.llvm.org/show_bug.cgi?id=45914
Bug ID: 45914
Summary: Using "long double" as asm register in x86_64 crashes
llc
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: dgreena...@google.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
When compiled with the command:
clang++ -O0 ./source.cc
clang crashes attempting to compile the following code on x86-64:
long double a;
void b() { __asm__("" : "=r"(a)); }
when I would instead expect an error message, such as "couldn't allocate output
register".
Possible duplicate of bug 26353.
Output of clang:
---
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: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
./output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0 -fcolor-diagnostics
-fno-crash-diagnostics -O0
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module ''.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z1bv'
#0 0x561c0339e14a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2bce14a)
#1 0x561c0339bf14 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2bcbf14)
#2 0x561c0339c185 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2bcc185)
#3 0x561c03314720 CrashRecoverySignalHandler(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2b44720)
#4 0x7f5f1fd16890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#5 0x561c02b36a24 llvm::EVT::isExtendedVector() const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2366a24)
#6 0x561c01ffad43
llvm::TargetLoweringBase::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x182ad43)
#7 0x561c03fe40dd llvm::SelectionDAGBuilder::visitInlineAsm(llvm::CallBase
const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x38140dd)
#8 0x561c03fcd345 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst
const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x37fd345)
#9 0x561c03ff4c4a llvm::SelectionDAGBuilder::visit(llvm::Instruction
const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3824c4a)
#10 0x561c0403fb21
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>,
llvm::ilist_iterator, false, true>, bool&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x386fb21)
#11 0x561c04043c0b
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3873c0b)
#12 0x561c04045a8d
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(.part.812) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3875a8d)
#13 0x561c0236f232 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x1b9f232)
#14 0x561c02949720
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2179720)
#15 0x561c02cf96bf llvm::FPPassManager::runOnFunction(llvm::Function&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x25296bf)
#16 0x561c02cf9db1 llvm::FPPassManager::runOnModule(llvm::Module&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2529db1)
#17 0x561c02cfa1b1 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x252a1b1)
#18 0x561c03613828 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr >)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e43828)
#19 0x561c036153ea clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e453ea)
#20 0x561c0413babc
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x396babc)
#21 0x561c04e39269 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4669269)
#22 0x561c03b71839 clang::FrontendAction::Execute()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x33a1839)
#23 0x561c03b2cb03
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/opt/compiler-e
[llvm-bugs] [Bug 45915] New: clang crashes after parsing bad C++17 deduction guide declaration
https://bugs.llvm.org/show_bug.cgi?id=45915 Bug ID: 45915 Summary: clang crashes after parsing bad C++17 deduction guide declaration Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dgreena...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk The following code: ``` template class b; b() b c; ``` compiled with `clang++ -std=c++17` causes clang to crash with the following error: --- :1:11: error: unknown type name 'a' template class b; ^ :2:1: error: deduction guide declaration without trailing return type b() b c; ^ :2:4: error: expected ';' after top level declarator b() b 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: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o ./output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0 -fcolor-diagnostics -fno-crash-diagnostics -O2 -std=c++17 1. :2:8: current parser token ';' #0 0x55a39034714a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x2bce14a) #1 0x55a390344f14 llvm::sys::RunSignalHandlers() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x2bcbf14) #2 0x55a390345185 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x2bcc185) #3 0x55a3902bd720 CrashRecoverySignalHandler(int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x2b44720) #4 0x7ff85980f890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #5 0x55a3922736b6 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4afa6b6) #6 0x55a3920045a3 clang::Sema::ActOnUninitializedDecl(clang::Decl*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x488b5a3) #7 0x55a391dfc2ba clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x46832ba) #8 0x55a391e0f175 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4696175) #9 0x55a391de60f9 clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x466d0f9) #10 0x55a391de6df1 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.227) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x466ddf1) #11 0x55a391deccd9 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4673cd9) #12 0x55a391dee3e9 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x46753e9) #13 0x55a391de2059 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4669059) #14 0x55a390b1a839 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x33a1839) #15 0x55a390ad5b03 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x335cb03) #16 0x55a390bded4b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3465d4b) #17 0x55a38e5a5e8c cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0xe2ce8c) #18 0x55a38e5a2abd ExecuteCC1Tool(llvm::SmallVectorImpl&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0xe29abd) #19 0x55a3909b0455 void llvm::function_ref::callback_fn >, std::__cxx11::basic_string, std::allocator >*, bool*) const::'lambda'()>(long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3237455) #20 0x55a3902bd803 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x2b44803) #21 0x55a3909b10c0 clang::driver::CC1Command::Execute(llvm::ArrayRef >, std::__cxx11::basic_string, std::allocator >*, bool*
[llvm-bugs] [Bug 45914] Using "long double" as asm register in x86_64 crashes llc
https://bugs.llvm.org/show_bug.cgi?id=45914 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED CC||craig.top...@gmail.com Resolution|--- |FIXED Fixed By Commit(s)||38e0ab2f3a3dc03acba37efe311 ||c7c0a5b79 --- Comment #1 from Craig Topper --- Coincidentally I fixed this today in 38e0ab2f3a3dc03acba37efe311c7c0a5b79. It should now give an error instead of crashing. -- 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 45916] New: Bug relating to -fopenmp
https://bugs.llvm.org/show_bug.cgi?id=45916 Bug ID: 45916 Summary: Bug relating to -fopenmp Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: linhsu0...@qq.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 23485 --> https://bugs.llvm.org/attachment.cgi?id=23485&action=edit preprocessed source(s) and associated run script(s) For the source file `a_star.cpp`, once `-fopenmp` added, the compilation failed. Clang info: ``` clang version 9.0.0-2~ubuntu18.04.2 (tags/RELEASE_900/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin ``` OpenMP lib info: ``` Package: libomp-dev Version: 5.0.1-1 Priority: extra Section: universe/libdevel Source: openmprtl Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: LLVM Packaging Team Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 29.7 kB Depends: libomp5 (= 5.0.1-1) Suggests: libomp-doc Breaks: libiomp-dev (<< 3.7-1) Replaces: libiomp-dev (<< 3.7-1) Homepage: http://openmp.llvm.org/ Supported: 3y Download-Size: 5,088 B APT-Manual-Installed: yes APT-Sources: http://mirrors.aliyun.com/ubuntu bionic/universe amd64 Packages Description: LLVM OpenMP runtime - dev package The runtime is the part of the OpenMP implementation that your code is linked against, and that manages the multiple threads in an OpenMP program while it is executing. ``` -- 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 45917] New: ExecutionEngine fails to get constant value when BlockAddress is passed into the function parameter
https://bugs.llvm.org/show_bug.cgi?id=45917
Bug ID: 45917
Summary: ExecutionEngine fails to get constant value when
BlockAddress is passed into the function parameter
Product: libraries
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Generic Execution Engine Support
Assignee: unassignedb...@nondot.org
Reporter: tlawod...@gmail.com
CC: 1101.deb...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 23486
--> https://bugs.llvm.org/attachment.cgi?id=23486&action=edit
Interpreter bug related to ExecutionEngine
Overview:
ExecutionEngine::getConstantValue() in
lib/ExecutionEngine/ExecutionEngine.cpp fails to obtain constant pointer value
when BlockAddress is passed into the function parameter.
Steps to Reproduce:
1) Copy & Paste the ll code below, and save it as "bug.ll"
; ModuleID = './bug.c'
source_filename = "./bug.c"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: noinline nounwind optnone uwtable
define void @bug(i8*) #0 {
; There can be some code related to the parameter
; But they're not important in this issue
ret void
}
; Function Attrs: noinline nounwind optnone uwtable
define i32 @main(i32, i8**, i8**) #0 {
entry:
call void @bug(i8* blockaddress(@main,%entry))
ret i32 0
}
attributes #0 = { noinline nounwind optnone uwtable
"correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"
"less-precise-fpmad"="false" "min-legal-vector-width"="0"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false" "no-trapping-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false"
"use-soft-float"="false" }
2) Activate ExecutionEngine using lli's interpreter mode
$ lli -force-interpreter -O0 bug.ll
Actual Results:
The ExecutionEngine raises "Unknown constant pointer type!" exception and
the execution crashes.
Expected Results:
1. ExecutionEngine should get the appropriate constant address for
BlockAddress(Especially the basicblock)
2. The application should not crash.
Build Date & Hardware:
Build 2020-05-14 on Ubuntu Linux 18.04
Additional Builds and Platforms:
Occur On Build 2020-05-14 on macOS Catalina
Additional Information:
In ExecutionEngine::getConstantValue() in
lib/ExecutionEngine/ExecutionEngine.cpp, there is a code to process constant
pointer.
// Otherwise, we have a simple constant.
...
case Type::PointerTyID:
while (auto *A = dyn_cast(C)) {
C = A->getAliasee();
}
if (isa(C))
Result.PointerVal = nullptr;
else if (const Function *F = dyn_cast(C))
Result = PTOGV(getPointerToFunctionOrStub(const_cast(F)));
else if (const GlobalVariable *GV = dyn_cast(C))
Result = PTOGV(getOrEmitGlobalVariable(const_cast(GV)));
else
llvm_unreachable("Unknown constant pointer type!");
break;
...
It seems like there is no check for the BlockAddress, so there can be a
patch like the following code or similar.
// Otherwise, we have a simple constant.
...
case Type::PointerTyID:
while (auto *A = dyn_cast(C)) {
C = A->getAliasee();
}
if (isa(C))
Result.PointerVal = nullptr;
else if (const Function *F = dyn_cast(C))
Result = PTOGV(getPointerToFunctionOrStub(const_cast(F)));
else if (const GlobalVariable *GV = dyn_cast(C))
Result = PTOGV(getOrEmitGlobalVariable(const_cast(GV)));
else if (const BlockAddress *BA = dyn_cast(C))
Result = PTOGV(BA->getBasicBlock());
else
llvm_unreachable("Unknown constant pointer type!");
break;
...
--
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 45918] New: Local register variables using high-byte registers should cause a -Wgcc-compat warning
https://bugs.llvm.org/show_bug.cgi?id=45918
Bug ID: 45918
Summary: Local register variables using high-byte registers
should cause a -Wgcc-compat warning
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: josephcsi...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Consider this C function:
char f(void) {
register char x __asm__("dh");
__asm__("movb $42, %%dh" : "=r"(x));
return x;
}
When compiled with Clang, it will return 42, as expected. However, GCC doesn't
distinguish between "dh" and "dl", so it returns whatever happened to be in %dl
instead. They don't consider this a bug
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121) so likely won't be
changing it anytime soon. As such, we should emit a -Wgcc-compat warning for
local register variables using high-byte registers.
--
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 45919] New: Different AST exposed for functions tagged with __stdcall.
https://bugs.llvm.org/show_bug.cgi?id=45919 Bug ID: 45919 Summary: Different AST exposed for functions tagged with __stdcall. Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: emi...@crisal.io CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk, unassignedclangb...@nondot.org Depends on: 39705 See https://github.com/rust-lang/rust-bindgen/issues/1778. For the following function, there's a bunch of CXCursor_ParamDecl: typedef void EVT_VIGEM_X360_NOTIFICATION( void* Client, void* Target, unsigned char LargeMotor, unsigned char SmallMotor, unsigned char LedNumber, void* UserData ); typedef EVT_VIGEM_X360_NOTIFICATION *PFN_VIGEM_X360_NOTIFICATION; Now add __stdcall: typedef void __stdcall EVT_VIGEM_X360_NOTIFICATION( void* Client, void* Target, unsigned char LargeMotor, unsigned char SmallMotor, unsigned char LedNumber, void* UserData ); typedef EVT_VIGEM_X360_NOTIFICATION *PFN_VIGEM_X360_NOTIFICATION; And they go missing. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39705 [Bug 39705] Multiline doc comments in enums are copied to following variants -- 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 45896] clang creates a symbol it cannot demangle
https://bugs.llvm.org/show_bug.cgi?id=45896 Erik Pilkington changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||1c1fb350c59a9c79078959b2fa1 ||5e6d658934a56 Resolution|--- |FIXED --- Comment #1 from Erik Pilkington --- Looks like its tripping on the this expression "fpT", fixed here: 1c1fb350c59a9c79078959b2fa15e6d658934a56 -- 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 45920] New: lldb wrongly stopped at a statement for nesting loop using step instruction
https://bugs.llvm.org/show_bug.cgi?id=45920
Bug ID: 45920
Summary: lldb wrongly stopped at a statement for nesting loop
using step instruction
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 at small.c:4:10, address =
0x0040111b
(lldb) r
Process 13529 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 13529 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040111b a.out`main at small.c:4:10
1int main ()
2{
3 int x, y;
-> 4 for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
5for (y = -1; y <= 0; y++)
6 if ((x + 1 - y) != (int) (x + 1U - y))
7return 1;
(lldb) si -c 35
Process 13529 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x0040113a a.out`main at small.c:5:5
2{
3 int x, y;
4 for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
-> 5for (y = -1; y <= 0; y++)
6 if ((x + 1 - y) != (int) (x + 1U - y))
7return 1;
8 return 0;
(lldb) var
(int) x = 2147483646
(int) y = 1
(lldb) si
Process 13529 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x00401179 a.out`main at small.c:7:16
4 for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
5for (y = -1; y <= 0; y++)
6 if ((x + 1 - y) != (int) (x + 1U - y))
-> 7return 1;
8 return 0;
9}
(lldb)
/**
lldb is wrongly stopped at Line 7.
However, when setting breakpoint at Line 7. The program is directly exit.
***/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 7
Breakpoint 1: where = a.out`main + 74 at small.c:7:9, address =
0x0040115a
(lldb) r
Process 13589 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 13589 exited with status = 0 (0x)
$ cat small.c
int main ()
{
int x, y;
for (x = __INT_MAX__ - 1; x < __INT_MAX__; x++)
for (y = -1; y <= 0; y++)
if ((x + 1 - y) != (int) (x + 1U - y))
return 1;
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45921] New: lldb not directly stopped at a specified statement
https://bugs.llvm.org/show_bug.cgi?id=45921
Bug ID: 45921
Summary: lldb not directly stopped at a specified statement
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ clang -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 5
Breakpoint 1: where = a.out`sig + 13 at small.c:5:3, address =
0x0040114d
(lldb) r
Process 15731 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 15731 stopped
* thread #1, name = 'a.out', stop reason = signal SIGFPE: integer divide by
zero
frame #0: 0x00401193 a.out`main at small.c:10:9
7
8int main () {
9 signal(8, sig);
-> 10 k = i / j;
11 return 0;
12 }
(lldb) s
Process 15731 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x00401141 a.out`sig(s=0) at small.c:4
1#include
2
3static int i, j, k;
-> 4void sig (int s) {
5 exit(0);
6}
7
(lldb) s
Process 15731 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040114d a.out`sig(s=8) at small.c:5:3
2
3static int i, j, k;
4void sig (int s) {
-> 5 exit(0);
6}
7
8int main () {
(lldb)
/
As shows, LLDB not directly stopped at the specified statement Line 5. When
continue stepping, it will stopped at Line 5 again.
*/
$ cat small.c
#include
static int i, j, k;
void sig (int s) {
exit(0);
}
int main () {
signal(8, sig);
k = i / j;
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45922] New: Misleading warning -Winvalid-offsetof
https://bugs.llvm.org/show_bug.cgi?id=45922
Bug ID: 45922
Summary: Misleading warning -Winvalid-offsetof
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: shac...@shemesh.biz
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Consider the following program:
> #include
>
> struct Base {
> int foo;
> };
>
> struct Child : public Base {
> int bar;
> };
>
> int main() {
> std::cout<<"foo "< bar)<<"\n";
> }
When compiled, produces:
> $ clang++-8 -std=c++17 -o so so.cpp
> so.cpp:12:24: warning: offset of on non-standard-layout type 'Child'
> [-Winvalid-offsetof]
> std::cout<<"foo "< bar)<<"\n";
>^ ~~~
> /usr/include/clang/8.0.0/include/stddef.h:120:24: note: expanded from macro
> 'offsetof'
> #define offsetof(t, d) __builtin_offsetof(t, d)
>^ ~
> so.cpp:12:55: warning: offset of on non-standard-layout type 'Child'
> [-Winvalid-offsetof]
> std::cout<<"foo "< bar)<<"\n";
> ^ ~~~
> /usr/include/clang/8.0.0/include/stddef.h:120:24: note: expanded from macro
> 'offsetof'
> #define offsetof(t, d) __builtin_offsetof(t, d)
>^ ~
> 2 warnings generated.
The C++ specs claim that taking an offset from a non-standard layout struct is
conditionally supported. The warning says this is what I am doing, but does not
mention any obvious consequences (i.e. - so what?), and the warning's option,
invalid-offset, suggests this won't work at all.
I suggest rephrasing the warning to say that this case is "non-portable". Even
gcc's horrific:
> so.cpp:12:33: warning: offsetof within non-standard-layout type ‘Child’ is
> conditionally-supported [-Winvalid-offsetof]
> std::cout<<"foo "< bar)<<"\n";
> ^
while sending me on a standard diving expedition to see what "conditionally
supported" means, is better than clang, that simply doesn't tell me where I
stand.
--
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
