[llvm-bugs] [Bug 27050] ArgumentPromotion crashing with "An asserting value handle still pointed to this value!"
https://bugs.llvm.org/show_bug.cgi?id=27050 Davide Italiano changed: What|Removed |Added CC||dav...@freebsd.org 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33453] Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
https://bugs.llvm.org/show_bug.cgi?id=33453 Davide Italiano changed: 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33504] New: Thread Safety Analysis [-Wthread-safety-analysis] work wrong with shared lock
https://bugs.llvm.org/show_bug.cgi?id=33504 Bug ID: 33504 Summary: Thread Safety Analysis [-Wthread-safety-analysis] work wrong with shared lock Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: antinett...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18656 --> https://bugs.llvm.org/attachment.cgi?id=18656&action=edit Example code When I use -Wthread-safety-analysis flag for code with wrapper for std::shared_lock I have warning: main.cpp:110:1: warning: releasing mutex 'lg_shared' using shared access, expected exclusive access [-Wthread-safety-analysis] So RELEASE_SHARED() attribute not works with ACQUIRE_SHARED() for scoped capability. Example code in attachment. build command: clang++-4.0 -o main main.cpp -std=c++14 -lboost_system -lboost_thread -pthread -Wthread-safety clang++-4.0 -v clang version 4.0.1-svn305187-1~exp1 (branches/release_40) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin -- 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 32893] When building with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON unit test Support/DynamicLibrary/DynamicLibraryTest fails in Linux
https://bugs.llvm.org/show_bug.cgi?id=32893 Roger Ferrer Ibanez changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #4 from Roger Ferrer Ibanez --- Fixed in http://llvm.org/viewvc/llvm-project?view=revision&revision=305181 -- 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 33505] New: revision 305395 breaks "llvm-config --libs"
https://bugs.llvm.org/show_bug.cgi?id=33505 Bug ID: 33505 Summary: revision 305395 breaks "llvm-config --libs" Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: octopl...@yandex.com CC: llvm-bugs@lists.llvm.org, ztur...@google.com Since r305395 I get: % llvm-config --libs llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/trippels/llvm-install/lib/libLLVMTestingSupport.a -- 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 33386] LLVM ERROR: Error parsing inline asm
https://bugs.llvm.org/show_bug.cgi?id=33386 Dimitry Andric changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #12 from Dimitry Andric --- Indeed, upstream fixed it here: https://github.com/openssl/openssl/commit/68b4a6e91f5acd42489bb9d1c580acc5ae457cad Let's mark this as 'not a bug', then. -- 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 33506] New: /lldmap emits an empty file
https://bugs.llvm.org/show_bug.cgi?id=33506 Bug ID: 33506 Summary: /lldmap emits an empty file 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 18657 --> https://bugs.llvm.org/attachment.cgi?id=18657&action=edit Test Repro I am testing on Windows 10. -- 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 33507] New: Assertion failed: Shift >= 0, file C:\src\llvm_package_303050\llvm\tools\clang\lib\Format\WhitespaceManager.cpp, line 245
https://bugs.llvm.org/show_bug.cgi?id=33507
Bug ID: 33507
Summary: Assertion failed: Shift >= 0, file
C:\src\llvm_package_303050\llvm\tools\clang\lib\Format
\WhitespaceManager.cpp, line 245
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: mteo...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
We have a dozen of C++ files with some lambdas that make clang-format crash.
One example is this code:
auto found = range::find_if(vsProducts, [&](auto * aProduct) {
static const Version verVs2017;
return true;
});
If I add this code to another C++ file and try to format (on save), it will
crash and create a dump file. (the example code was reduced, but still two
lines)
I've trimmed the config file to just these two lines to reproduce the problem:
BasedOnStyle: Mozilla
AlignConsecutiveDeclarations: 'true'
Thanks
--
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 33508] New: Tablegen does not use correct namespace for AsmMatcher
https://bugs.llvm.org/show_bug.cgi?id=33508 Bug ID: 33508 Summary: Tablegen does not use correct namespace for AsmMatcher Product: tools Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: TableGen Assignee: unassignedb...@nondot.org Reporter: e.j.v.d@student.tue.nl CC: llvm-bugs@lists.llvm.org For an architecture I am working on the target name is different from the namespace we use in tablegen. Tablegen does not produce a valid asmMatcher in this case. In the MatchTable the namespace of the instruction name is target name instead of the register class namespace. (utils/TableGen/AsmMatcherEmitter.cpp:2951) ValidateOperandClass when Operand.isReg() target name is used for the registers instead of decodernamespace. (utils/TableGen/AsmMatcherEmitter.cpp:2225) -- 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 33509] New: [mc][gfx9][Disassembler] Assertion failed with v_pk_add/ashrrev/fma/lshlrev/max/min/mul/mul_lo/sub_X16
https://bugs.llvm.org/show_bug.cgi?id=33509 Bug ID: 33509 Summary: [mc][gfx9][Disassembler] Assertion failed with v_pk_add/ashrrev/fma/lshlrev/max/min/mul/mul_lo/sub_X1 6 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: ASSIGNED Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: artem.tama...@amd.com CC: andrey.kasau...@gmail.com, artem.tama...@amd.com, dfuka...@gmail.com, dpreobrazhen...@luxoft.com, i.am.permi...@gmail.com, llvm-bugs@lists.llvm.org, nikolay.haus...@amd.com, sam.kol...@amd.com, valery.pykh...@gmail.com Created attachment 18659 --> https://bugs.llvm.org/attachment.cgi?id=18659&action=edit Lit tests (produced by by TestGen 1.9) Example of failing disassembly: > 0x05,0x80,0x83,0xd3,0x01,0x05,0x02,0x18 Output: > Assertion failed: idx < size(), file > C:\work-1\asm-git-2\llvm\include\llvm/ADT/SmallVector.h, line 153 > #0 0x0065d779 (C:\work-1\asm-git-2\build\Debug\bin\llvm-mc.EXE+0x2dd779) > #1 0x692515db (C:\Windows\system32\ucrtbased.dll+0xb15db) > #2 0x69252ba2 (C:\Windows\system32\ucrtbased.dll+0xb2ba2) > ... Actual instruction is: > v_pk_sub_i16 v5, v1, v2 clamp Tested with > r305694 | fe252ff | florian.hahn | 2017-06-19 16:45:41 +0300 Lit tests (produced by by TestGen 1.9) attached. -- 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 32141] crash with "-O3 -m64" on x86_64-linux-gnu (Assertion `Idx >= 0 && "Invalid basic block argument!"' failed.)
https://bugs.llvm.org/show_bug.cgi?id=32141 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Davide Italiano --- Doesn't repro anymore. -- 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 33510] New: Clang ignores NANs with -ffast-math and -fhonor-nans (or -fno-finite-math-only)
https://bugs.llvm.org/show_bug.cgi?id=33510
Bug ID: 33510
Summary: Clang ignores NANs with -ffast-math and -fhonor-nans
(or -fno-finite-math-only)
Product: clang
Version: 3.9
Hardware: Macintosh
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ebori...@gmail.com
CC: llvm-bugs@lists.llvm.org
## Summary: In contrast with GCC -- and apparently its own internal
## attributes states -- clang ignores NANs when compiling with :
## -ffast-math and (-fhonor-nans or -fno-finite-math-only)
## Test code: (nanfunc.c)
int testfunc(float x) {return x == x;}
## TEST 1: clang -O3 -S -emit-llvm -o - nanfunc.c
## This version checks for NANs (fcmp ord)
## Outputs are trimmed to the interesting parts
define i32 @testfunc(float) local_unnamed_addr #0 {
%2 = fcmp ord float %0, 0.00e+00
%3 = zext i1 %2 to i32
ret i32 %3
}
attributes #0 = { norecurse nounwind readnone ssp uwtable
"disable-tail-calls"="false" "less-precise-fpmad"="false"
"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" "stack-protector-buffer-size"="8"
"target-cpu"="core2"
"target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+ssse3,+x87"
"unsafe-fp-math"="false" "use-soft-float"="false" }
## TEST 2: clang -O3 -ffast-math -S -emit-llvm -o - nanfunc.c
## This version converts (x==x) to (1) as expected for no NANs allowed.
## Note all the changes in attributes from -ffast-math, especially
## no-nans-fp-math=true
define i32 @testfunc(float) local_unnamed_addr #0 {
ret i32 1
}
attributes #0 = { norecurse nounwind readnone ssp uwtable
"disable-tail-calls"="false" "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="true" "no-jump-tables"="false" "no-nans-fp-math"="true"
"no-signed-zeros-fp-math"="true" "stack-protector-buffer-size"="8"
"target-cpu"="core2"
"target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+ssse3,+x87"
"unsafe-fp-math"="true" "use-soft-float"="false" }
## TEST 2: clang -O3 -ffast-math -fhonor-nans -S -emit-llvm -o - nanfunc.c
## This version still(!) converts (x==x) to (1). Note in the attributes
## that it has parsed the option and set no-nans-fp-math=false, but it
## doesn't seem to have followed that restriction.
define i32 @testfunc(float) local_unnamed_addr #0 {
ret i32 1
}
attributes #0 = { norecurse nounwind readnone ssp uwtable
"disable-tail-calls"="false" "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="true" "no-jump-tables"="false" "no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="true" "stack-protector-buffer-size"="8"
"target-cpu"="core2"
"target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+ssse3,+x87"
"unsafe-fp-math"="true" "use-soft-float"="false" }
## TEST 3: clang -O3 -ffast-math -ffinite-math-only -S -emit-llvm -o -
nanfunc.c
## Same functional output as TEST 2; a few additional optimizations
## attributes change (no-infs-fp-math, signed-zeros)
; Function Attrs: norecurse nounwind readnone ssp uwtable
define i32 @testfunc(float) local_unnamed_addr #0 {
ret i32 1
}
attributes #0 = { norecurse nounwind readnone ssp uwtable
"disable-tail-calls"="false" "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="true" "no-jump-tables"="false" "no-nans-fp-math"="true"
"no-signed-zeros-fp-math"="true" "stack-protector-buffer-size"="8"
"target-cpu"="core2"
"target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+ssse3,+x87"
"unsafe-fp-math"="true" "use-soft-float"="false" }
## Note: this is different from GCC's behavior, where -ffast-math elides
## the (x==x) check, but '-ffast-math -fno-finite-math-only' does not.
--
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 33511] New: Wrong relocation for an expression on ARM
https://bugs.llvm.org/show_bug.cgi?id=33511 Bug ID: 33511 Summary: Wrong relocation for an expression on ARM Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Given .Lfoo: .word _GLOBAL_OFFSET_TABLE_(GOT_PREL) - (.Lfoo+8) .word _GLOBAL_OFFSET_TABLE_ - (.Lfoo+8) gas produces 0660 R_ARM_GOT_PREL _GLOBAL_OFFSET_TABLE_ 0004 0619 R_ARM_BASE_PREL _GLOBAL_OFFSET_TABLE_ MC produces 0160 R_ARM_GOT_PREL _GLOBAL_OFFSET_TABLE_ 0004 0103 R_ARM_REL32 _GLOBAL_OFFSET_TABLE_ -- 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 33461] clang crashes with "-mllvm -enable-newgvn": Assertion `Res.second && "Stored expression conflict exists in expression table"' failed.
https://bugs.llvm.org/show_bug.cgi?id=33461 Davide Italiano changed: What|Removed |Added 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33512] New: target-cpu=kryo incomplete machine model
https://bugs.llvm.org/show_bug.cgi?id=33512
Bug ID: 33512
Summary: target-cpu=kryo incomplete machine model
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
$ cat 1.ii
struct __attribute__((__aligned__)) C {};
_Atomic C c;
void g() { __c11_atomic_load(&c, __ATOMIC_RELAXED); }
$ clang++ -c -mcpu=kryo -O1 -target aarch64-linux -std=c++14 1.ii
DefIdx 1 exceeds machine model writes for %vreg1, %vreg2 = LDXPX
%vreg0; mem:Volatile LD16[getelementptr inbounds (%struct.C, %struct.C* @c, i32
0, i32 0, i32 0)] GPR64:%vreg1,%vreg2 GPR64common:%vreg0
(Try with MCSchedModel.CompleteModel set to false)incomplete machine model
UNREACHABLE executed at /code/llvm/lib/CodeGen/TargetSchedule.cpp:249!
The same with IR:
$ cat 1.ll
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64--linux"
%struct.C = type { [16 x i8] }
@c = local_unnamed_addr global %struct.C zeroinitializer, align 16
define void @g() #0 {
entry:
%0 = load atomic i128, i128* bitcast (%struct.C* @c to i128*) monotonic,
align 16
ret void
}
attributes #0 = { "target-cpu"="kryo" }
$ llc 1.ll
[[same error message]]
--
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 33512] target-cpu=kryo incomplete machine model
https://bugs.llvm.org/show_bug.cgi?id=33512 Evgeniy Stepanov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Evgeniy Stepanov --- Sorry, this has already been filed. Strange that it did not pop up in my google search. *** This bug has been marked as a duplicate of bug 33491 *** -- 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 20522] clang++ crash wz 32 bit
https://bugs.llvm.org/show_bug.cgi?id=20522 Tim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tim --- SOLVED I had installed fbsd32 on a 64bit machine. -- 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 33513] New: clang frontend crash: Assertion `!NodePtr->isKnownSentinel()' failed.
https://bugs.llvm.org/show_bug.cgi?id=33513 Bug ID: 33513 Summary: clang frontend crash: Assertion `!NodePtr->isKnownSentinel()' failed. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: nyqu...@chromium.org CC: llvm-bugs@lists.llvm.org Created attachment 18660 --> https://bugs.llvm.org/attachment.cgi?id=18660&action=edit crash backtrace, preprocessed source, associated run script, DEPS-file, GN args Host OS/Arch: Linux/x86_64 Target OS/Arch: Android/mipsel Steps to reproduce: 1. Check out Chromium for Android: $ # git clone depot tools, etc. $ fetch android 2. Sync to src@fe00e8f82df4a3dd7dd0ec9cc6a7097506d45e65 $ gclient sync -r src@fe00e8f82df4a3dd7dd0ec9cc6a7097506d45e65 3. Generate ninja build files: $ gn gen out-android/mips --args="target_os=\"android\" target_cpu=\"mipsel\" is_component_build=false is_debug=true" 4. Run build: $ ninja -C out-android/mips skia Expected result: A successful build. Actual result: clang: /b/build/slave/linux_upload_clang/build/src/third_party/llvm/include/llvm/ADT/ilist_iterator.h:140: llvm::ilist_iterator::reference llvm::ilist_iterator, false, false>::operator*() const [OptionsT = llvm::ilist_detail::node_options, IsReverse = false, IsConst = false]: Assertion `!NodePtr->isKnownSentinel()' failed. #0 0x01d15fe4 (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1d15fe4) #1 0x01d16306 (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1d16306) #2 0x7f7aa37e4330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7f7aa23d5c37 gsignal /build/eglibc-MjiXCM/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7f7aa23d9028 abort /build/eglibc-MjiXCM/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7f7aa23cebf6 __assert_fail_base /build/eglibc-MjiXCM/eglibc-2.19/assert/assert.c:92:0 #6 0x7f7aa23ceca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x00ec7d60 (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0xec7d60) #8 0x015b9734 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x15b9734) #9 0x018983cf llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x18983cf) #10 0x01898623 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1898623) #11 0x01898b25 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1898b25) #12 0x01ea2d4f 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 >) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1ea2d4f) #13 0x025cb677 (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x25cb677) #14 0x022b17dc clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x22b17dc) #15 0x02a37546 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x2a37546) #16 0x0228be68 clang::FrontendAction::Execute() (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x228be68) #17 0x0223c661 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x223c661) #18 0x023126aa clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x23126aa) #19 0x00842724 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x842724) #20 0x0084029c main (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x84029c) #21 0x7f7aa23c0f45 __libc_start_main /build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:321:0 #22 0x0083d729 _start (/usr/local/google/codefast/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x83d7
[llvm-bugs] [Bug 33514] New: False heap buffer overflow error in ASan after r304824
https://bugs.llvm.org/show_bug.cgi?id=33514
Bug ID: 33514
Summary: False heap buffer overflow error in ASan after r304824
Product: new-bugs
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: evstu...@gmail.com, k...@google.com,
llvm-bugs@lists.llvm.org, qcolom...@apple.com
Created attachment 18661
--> https://bugs.llvm.org/attachment.cgi?id=18661&action=edit
creduced repro
A Chrome test started failing under ASan after r304824. Reproduction in a
Chromium build:
#include
#include
using namespace std;
struct DataView {
DataView() {}
bool ReadBinary(std::vector *v) const {
v->push_back(1);
return true;
}
};
void g(const std::string &s) {
volatile void* p = (volatile void*)&s;
}
bool f(const DataView &data_view) {
std::vector binary;
if (!data_view.ReadBinary(&binary))
return false;
g(std::string(binary.data(), binary.data() + binary.size()));
return true;
}
int main() {
DataView d;
f(d);
return 0;
}
$ ../../third_party/llvm-build/Release+Asserts/bin/clang -fsanitize=address
-fsanitize-coverage=trace-pc-guard -O2 -g1 -nostdinc++
-isystem../../buildtools/third_party/libc++/trunk/include
-isystem../../buildtools/third_party/libc++abi/trunk/include /tmp/a.cc
./libc++.so -Wl,-rpath=\$ORIGIN/. && ASAN_OPTIONS=symbolize=1 ./a.out
=
==66042==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200011 at pc 0x004e4c59 bp 0x7ffd344de930 sp 0x7ffd344de928
READ of size 1 at 0x60200011 thread T0
#0 0x4e4c58 in __init
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/string:1847:35
#1 0x4e4c58 in basic_string
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/string:1856
#2 0x4e4c58 in f(DataView const&) /tmp/a.cc:17
#3 0x4e4fe9 in main /tmp/a.cc:23:3
#4 0x7fb6289b7f44 in __libc_start_main
/build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:287
#5 0x41999b in _start
(/usr/local/google/work/chromium/src/out/asan/a.out+0x41999b)
0x60200011 is located 0 bytes to the right of 1-byte region
[0x60200010,0x60200011)
allocated by thread T0 here:
#0 0x4b9363 in malloc
(/usr/local/google/work/chromium/src/out/asan/a.out+0x4b9363)
#1 0x7fb629a5dc1d in operator new(unsigned long)
out/asan/../../buildtools/third_party/libc++/trunk/src/new.cpp:70:17
#2 0x4e5177 in __allocate
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/new:226:10
#3 0x4e5177 in allocate
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/memory:1786
#4 0x4e5177 in allocate
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/memory:1541
#5 0x4e5177 in __split_buffer
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/__split_buffer:309
#6 0x4e5177 in void std::__1::vector >::__push_back_slow_path(unsigned char const&)
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/vector:1572
#7 0x7ffd344de99f ()
SUMMARY: AddressSanitizer: heap-buffer-overflow
/work/chromium/src/out/asan/../../buildtools/third_party/libc++/trunk/include/string:1847:35
in __init
Shadow bytes around the buggy address:
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa[01]fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==66042==ABORTING
Attaching a creduced repro that's harder to read but might be easier t
[llvm-bugs] [Bug 33506] /lldmap emits an empty file
https://bugs.llvm.org/show_bug.cgi?id=33506 Rui Ueyama changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Rui Ueyama --- Fixed in r305718. But I think we need our own thread-safe demangler in LLVM. I'll start a thread in llvm-dev. -- 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 33515] New: clang should not generate counting function for functions with no_instrument_function attribute.
https://bugs.llvm.org/show_bug.cgi?id=33515
Bug ID: 33515
Summary: clang should not generate counting function for
functions with no_instrument_function attribute.
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: manojgu...@google.com
Reporter: manojgu...@google.com
CC: llvm-bugs@lists.llvm.org
When -pg is used, clang generates counting functions even for functions with
no_instrument_function attribute.
This results in a Linux kernel crash when function tracing is enabled in Chrome
OS.
GCC behavior is to not generate any counting functions with
no_instrument_function attribute.
Apparently, this is also desired in clang according to the comment in
SemaDeclAttr.cpp but the implementation is broken.
llvm/tools/clang/lib/Sema/SemaDeclAttr.cpp: case
AttributeList::AT_NoInstrumentFunction: // Interacts with -pg.
$ cat pg.c
__attribute__((no_instrument_function)) void foo()
{
}
$ clang pg.c -c -pg -target aarch64-unknown-linux-gnu
$ aarch64-linux-gnu-objdump -d pg.o
Disassembly of section .text:
:
0: e92d4800push{fp, lr}
4: e1a0b00dmov fp, sp
8: ebfebl 0 <_mcount> // _mcount should not be generated
c: e8bd8800pop {fp, pc}
--
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 33515] clang should not generate counting function for functions with no_instrument_function attribute.
https://bugs.llvm.org/show_bug.cgi?id=33515 Manoj Gupta changed: What|Removed |Added 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23257] [LegacyPassManager] Add -print-func-after-all command-line options
https://bugs.llvm.org/show_bug.cgi?id=23257 Chad Rosier changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Chad Rosier --- This was fixed by Weiming in r256987. -- 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 33475] r305468 causes 'Assertion failed: (MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!"), function getLoad'
https://bugs.llvm.org/show_bug.cgi?id=33475 Nirav Dave changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nirav Dave --- Bug was due to incorrect selection logic between truncated store and normal store branches. unreverted @ r305701. -- 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 33491] [AArch64, Kryo] Assertion on atomic i128 load
https://bugs.llvm.org/show_bug.cgi?id=33491 Geoff Berry changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Geoff Berry --- Fixed by r305751 -- 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 33516] New: Build failure on ppc64: include/chrono:374:59: error: ‘(9.223372036854775807e+18 / 1.0e+9)’ is not a constant expression
https://bugs.llvm.org/show_bug.cgi?id=33516 Bug ID: 33516 Summary: Build failure on ppc64: include/chrono:374:59: error: ‘(9.223372036854775807e+18 / 1.0e+9)’ is not a constant expression Product: libc++ Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: tstel...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com libc++ build fails on ppc64 linux, with gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) llvm.src/projects/libcxx/include/chrono:413:67: in constexpr expansion of ‘std::__1::chrono::__duration_cast >, std::__1::chrono::duration, std::__1::ratio<1l, 10l>, true, false>().std::__1::chrono::__duration_cast<_FromDuration, _ToDuration, _Period, true, false>::operator() >, std::__1::chrono::duration, std::__1::ratio<1l, 10l> >(__fd)’ /home/tmp.OkzzGfk9Zm/rc3/llvm.src/projects/libcxx/include/chrono:374:59: error: ‘(9.223372036854775807e+18 / 1.0e+9)’ is not a constant expression static_cast<_Ct>(__fd.count()) / static_cast<_Ct>(_Period::den))); ~~~^~~~ -- 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 33517] New: Crash using llvm-cov with missing function names in profile data
https://bugs.llvm.org/show_bug.cgi?id=33517 Bug ID: 33517 Summary: Crash using llvm-cov with missing function names in profile data Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: v...@apple.com Reporter: efrie...@codeaurora.org CC: llvm-bugs@lists.llvm.org I ran into a bug with binutils ld dropping the __llvm_prf_names section in my profile binary. (Apparently, this is fixed in version 2.26, but my system has 2.24 installed.) The generated profile file was therefore missing the names. llvm-cov then crashed with the following assertion: llvm-cov: llvm/include/llvm/ADT/StringSet.h:33: std::pair llvm::StringSet::insert(llvm::StringReflocatorTy = llvm::MallocAllocator]: Assertion `!Key.empty()' failed. I ran into this running a build LLVM with -DLLVM_BUILD_INSTRUMENTED_COVERAGE=On on Ubuntu 14.04, then using prepare-code-coverage-artifact.py on llvm-tblgen. I specified CC to point to at trunk clang; host binutils is 2.24. Having trouble coming up with a testcase, short of uploading the llvm-tblgen that ran into the problem. (It doesn't seem to happen for all binaries.) Apparently I ended up with something slightly different from what would happen if you just ran "strip -R __llvm_prf_names" on a binary with instrumentation; that also leads to a crash, but it's a slightly different one in llvm-profdata. I can dig a bit more if I had some idea what I'm looking for. -- 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 33519] New: llvm-pdbutil crash with bad runtime enum value
https://bugs.llvm.org/show_bug.cgi?id=33519 Bug ID: 33519 Summary: llvm-pdbutil crash with bad runtime enum value Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: brenda...@nyu.edu CC: llvm-bugs@lists.llvm.org The PDB file found here: http://panda.moyix.net/~moyix/llvm_pdb_bug/ehiitv.pdb Causes "llvm-pdbutil pdb2yaml -all" to hit an unreachable switch case. I think this is similar to Bug 33428 and probably has the same fix. Stack trace: bad runtime enum value UNREACHABLE executed at /home/moyix/git/llvm-master/lib/Support/YAMLTraits.cpp:580! #0 0x0070b5c9 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/moyix/git/llvm-master/lib/Support/Unix/Signals.inc:398:0 #1 0x0070b65c PrintStackTraceSignalHandler(void*) /home/moyix/git/llvm-master/lib/Support/Unix/Signals.inc:462:0 #2 0x007098a3 llvm::sys::RunSignalHandlers() /home/moyix/git/llvm-master/lib/Support/Signals.cpp:49:0 #3 0x0070ae3e SignalHandler(int) /home/moyix/git/llvm-master/lib/Support/Unix/Signals.inc:252:0 #4 0x7f318201b390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #5 0x7f31811ac428 gsignal /build/glibc-9tT8Do/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0 #6 0x7f31811ae02a abort /build/glibc-9tT8Do/glibc-2.23/stdlib/abort.c:91:0 #7 0x006bc144 bindingsErrorHandler(void*, std::__cxx11::basic_string, std::allocator > const&, bool) /home/moyix/git/llvm-master/lib/Support/ErrorHandling.cpp:127:0 #8 0x006d32d7 llvm::yaml::Output::endEnumScalar() /home/moyix/git/llvm-master/lib/Support/YAMLTraits.cpp:581:0 #9 0x004b2a76 std::enable_if::value, void>::type llvm::yaml::yamlize(llvm::yaml::IO&, llvm::pdb::PDB_Machine&, bool, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:757:0 #10 0x004afeb5 void llvm::yaml::IO::processKeyWithDefault(char const*, llvm::pdb::PDB_Machine&, llvm::pdb::PDB_Machine const&, bool, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:716:0 #11 0x004ade89 void llvm::yaml::IO::mapOptionalWithContext(char const*, llvm::pdb::PDB_Machine&, llvm::pdb::PDB_Machine const&, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:682:0 #12 0x004ad28e void llvm::yaml::IO::mapOptional(char const*, llvm::pdb::PDB_Machine&, llvm::pdb::PDB_Machine const&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:655:0 #13 0x004aa43e llvm::yaml::MappingTraits::mapping(llvm::yaml::IO&, llvm::pdb::yaml::PdbDbiStream&) /home/moyix/git/llvm-master/tools/llvm-pdbutil/PdbYaml.cpp:201:0 #14 0x004b3c7e void llvm::yaml::detail::doMapping(llvm::yaml::IO&, llvm::pdb::yaml::PdbDbiStream&, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:747:0 #15 0x004b1cca std::enable_if::value, void>::type llvm::yaml::yamlize(llvm::yaml::IO&, llvm::pdb::yaml::PdbDbiStream&, bool, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:846:0 #16 0x004af1e8 void llvm::yaml::IO::processKeyWithDefault(char const*, llvm::Optional&, llvm::Optional const&, bool, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:700:0 #17 0x004ad8e4 void llvm::yaml::IO::mapOptionalWithContext(char const*, llvm::Optional&, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:668:0 #18 0x004ace15 void llvm::yaml::IO::mapOptional >(char const*, llvm::Optional&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:649:0 #19 0x004a9f4a llvm::yaml::MappingTraits::mapping(llvm::yaml::IO&, llvm::pdb::yaml::PdbObject&) /home/moyix/git/llvm-master/tools/llvm-pdbutil/PdbYaml.cpp:155:0 #20 0x00453186 void llvm::yaml::detail::doMapping(llvm::yaml::IO&, llvm::pdb::yaml::PdbObject&, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:747:0 #21 0x0044ca06 std::enable_if::value, void>::type llvm::yaml::yamlize(llvm::yaml::IO&, llvm::pdb::yaml::PdbObject&, bool, llvm::yaml::EmptyContext&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:846:0 #22 0x0051069a std::enable_if::value, llvm::yaml::Output&>::type llvm::yaml::operator<< (llvm::yaml::Output&, llvm::pdb::yaml::PdbObject&) /home/moyix/git/llvm-master/include/llvm/Support/YAMLTraits.h:1487:0 #23 0x0050eeb4 llvm::pdb::YAMLOutputStyle::flush() /home/moyix/git/llvm-master/tools/llvm-pdbutil/YAMLOutputStyle.cpp:332:0 #24 0x0050cec3 llvm::pdb::YAMLOutputStyle::dump() /home/moyix/git/llvm-master/tools/llvm-pdbutil/YAMLOutputStyle.cpp:76:0 #25 0x00434eec pdb2Yaml(
[llvm-bugs] [Bug 33517] Crash using llvm-cov with missing function names in profile data
https://bugs.llvm.org/show_bug.cgi?id=33517 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Vedant Kumar --- Should be addressed by: r305767 - [Coverage] PR33517: Check for failure to load func records r305765 - [ProfileData] PR33517: Check for failure of symtab creation This was a good opportunity to 'plug some holes' in the way we propagate up errors, thanks for the report. -- 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
