[llvm-bugs] [Bug 44208] New: clang-cl with coverage saves gcno files in root, rather than next to obj file
https://bugs.llvm.org/show_bug.cgi?id=44208
Bug ID: 44208
Summary: clang-cl with coverage saves gcno files in root,
rather than next to obj file
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: jeffrey.vandegl...@nobelbiocare.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
While trying to generate code coverage reports for our project, I had an issue
where multiple files with the same name caused issues regarding the writing of
gcda files. Searching online, everything pointed towards gcno files having to
be stored next to the obj files, but for me they were always in the root
folder.
After self-compiling the release_90 branch and inserting some debug prints I
noticed that my generated ninja files didn't contain a -o option. After adding
it, I noticed -o is interpreted as /o, and thus the line that checks for OPT_o
fails, since it is OPT__SLASH_o. It then simply falls back to taking PWD and
source file and generate a path in root.
I then noticed that the flag that clang-cl should actually be looking for is
OPT__SLASH_Fo
(https://docs.microsoft.com/en-us/cpp/build/reference/fo-object-file-name?view=vs-2019),
so I updated to code (Clang.cpp - addPGOAndCoverageFlags() ~ line 888) to look
like this:
CmdArgs.push_back("-coverage-notes-file");
SmallString<128> OutputFilename;
Arg *FinalOutput = C.getArgs().getLastArg(options::OPT_o);
if (!FinalOutput)
FinalOutput = C.getArgs().getLastArg(options::OPT__SLASH_Fo);
if (FinalOutput)
OutputFilename = FinalOutput->getValue();
This fixes the position of the gcno files. However, I do not know if I am
overseeing some other issues that might pop up due to this change.
My setup is:
Self compiled LLVM + Clang release_90
Microsoft Visual Studio 2019 x64 environment
CMake 3.15 + Ninja 1.9.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 13707] [meta] VCPP compatibility issues
https://bugs.llvm.org/show_bug.cgi?id=13707 Bug 13707 depends on bug 17129, which changed state. Bug 17129 Summary: [MSVC] clang-cl warns about flags from default Visual Studio build https://bugs.llvm.org/show_bug.cgi?id=17129 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 17129] [MSVC] clang-cl warns about flags from default Visual Studio build
https://bugs.llvm.org/show_bug.cgi?id=17129 Hans Wennborg 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26673] Wrong debugging information with -fsanitize=address (and memset?)
https://bugs.llvm.org/show_bug.cgi?id=26673 Johannes Altmanninger changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||09667bc1920463107684a566c3f ||2c3cef9b156e7 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 43145] [C++] Invalid cast when calling member function
https://bugs.llvm.org/show_bug.cgi?id=43145 Sven van Haastregt changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |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 44209] New: opt -disable-basicaa -loop-versioning causes "PHINode should have one entry for each predecessor of its parent basic block!"
https://bugs.llvm.org/show_bug.cgi?id=44209 Bug ID: 44209 Summary: opt -disable-basicaa -loop-versioning causes "PHINode should have one entry for each predecessor of its parent basic block!" Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 22886 --> https://bugs.llvm.org/attachment.cgi?id=22886&action=edit bbi-36190.ll reproducer llvm version: 039664db8 Reproduce with: opt -disable-basicaa -loop-versioning bbi-36190.ll -S -o - which gives PHINode should have one entry for each predecessor of its parent basic block! %d.1.lcssa.lver.orig = phi i16 [ undef, %for.body.lver.orig ], [ undef, %for.end ] in function f LLVM ERROR: Broken function found, compilation aborted! The input contains three blocks that are not reachable from entry: for.body3:; preds = %for.end br label %for.cond4 for.cond4:; preds = %for.cond4, %for.body3 br i1 undef, label %for.cond4, label %for.end for.end: ; preds = %for.cond4 br i1 undef, label %for.body3, label %for.inc Wouldn't be surprised if that is what is causing confusion. -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 44183, which changed state. Bug 44183 Summary: Clang 9 abort trap when building mesa drivers on FreeBSD https://bugs.llvm.org/show_bug.cgi?id=44183 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 44183] Clang 9 abort trap when building mesa drivers on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=44183 Nemanja Ivanovic changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from Nemanja Ivanovic --- Reopening for the merge request. I apologize if this is not the right thing to do and I should instead open a separate PR for the merge. If so, please let me know and I'll do that. -- 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 44175] unused member variable causes code to compile for member to function for undefined function
https://bugs.llvm.org/show_bug.cgi?id=44175
David Blaikie changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #2 from David Blaikie ---
Yeah, I'm going to resolve this as invalid - seems GCC and Clang both accept
the code, and it boils down to something like this:
struct Bad { };
template
struct is_Foo {
void (T::*hello)(int) = &T::hello;
constexpr static bool value=true;
};
int main() {
return is_Foo::value;
}
- instantiating the class and the static member 'value', doesn't instantiate
the non-static members.
--
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 43057] [C++] Lambdas can't compile
https://bugs.llvm.org/show_bug.cgi?id=43057 Anastasia Stulova changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Anastasia Stulova --- Fixed in https://reviews.llvm.org/rG980133a2098cf6159785b8ac0cbe4d8fbf99bfea -- 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 44210] New: llvm-mc chokes on .file directives generated by clang -S
https://bugs.llvm.org/show_bug.cgi?id=44210
Bug ID: 44210
Summary: llvm-mc chokes on .file directives generated by clang
-S
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: lab...@google.com
CC: cmt...@google.com, echri...@gmail.com,
jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
I think this example says it all
=
$ echo "void foo(){}" > test.c
$ clang -gmlt -gdwarf-5 ./test.c -c -o a.o # everything OK here
$ clang -gmlt -gdwarf-5 ./test.c -S -o - | llvm-mc -filetype=obj -o a.o -
-dwarf-version=5
:10:7: error: unassigned file number in '.loc' directive
.loc1 1 0 # ./test.c:1:0
^
:19:7: error: unassigned file number in '.loc' directive
.loc1 1 12 prologue_end # ./test.c:1:12
=
This is kind of related to pr44170, as the trigger for it is pretty subtle
(it's the "./" part -- see that bug for details).
--
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 44211] New: LLVM ThreadPoolExecutor incompatible with Windows global destructors in a DLL
https://bugs.llvm.org/show_bug.cgi?id=44211 Bug ID: 44211 Summary: LLVM ThreadPoolExecutor incompatible with Windows global destructors in a DLL Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: laure...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org When using the LLVM ThreadPoolExecutor (lib/Support/Parallel.cpp) on Windows within a DLL, its global destructor will deadlock on DLL unload (or process shutdown). In short: In DLLs, by the time that global destructors are called in a DLL, all threads have been forcibly stopped already, making global destructors that rely on thread shutdown handshakes unworkable. LLVM's ThreadPoolExecutor is one such thing. This can be seen by setting a breakpoint in the work() method and the destructor. You will note that by the time the destructor is called, there are no further threads running, and you will never hit the breakpoint (prior to that) where the thread exits. This is the same root cause as encountered on the dlib project (which is where I found some debugging inspiration): https://github.com/davisking/dlib/issues/505 I do not have a repro of this issue currently as I am working quite downstream and it requires a specific setup on Windows to trigger. However, it took a fair bit of diagnostic work that would be helpful to have captured. Since the ThreadPoolExecutor is sparsely used at present, this may be a newly discovered issue. I believe that in the current state, it would only affect LLDB when used in a DLL (or MLIR from a DLL, which is where I encountered this). My fix was to disable LLVM threading on windows. The consensus from others seems to be that a fix would involve some Windows specific code that installed an atexit hook on static construction. This hook would poke the ThreadPoolExecutor and tell it to do an orderly shutdown. Apparently on Windows, an atexit hook in a DLL is called before the OS forcibly stops dependent threads. -- 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 44212] New: Type pruning not working when casting/indirection is used
https://bugs.llvm.org/show_bug.cgi?id=44212 Bug ID: 44212 Summary: Type pruning not working when casting/indirection is used Product: clang Version: 8.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: stan.kva...@mediatek.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22887 --> https://bugs.llvm.org/attachment.cgi?id=22887&action=edit testcase Clang emits incorrect TBAA information when accessing a union member with any kind of casting. In the example attached, r.w[i] gets the right TBAA type info of omnipotent char. Any other access like ((int*)r.w)[i] or *(r.w + i) gets TBAA int type. This leads to incorrect optimization as shown in the attachment. -- 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 44011] line coverage shows coverage of unreachable whitespace in switch statements
https://bugs.llvm.org/show_bug.cgi?id=44011 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||859bf4d2bea2404bd2eac92451f ||2db4371ec6eb4 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 44213] New: DW_AT_LLVM_isysroot isn't useful
https://bugs.llvm.org/show_bug.cgi?id=44213
Bug ID: 44213
Summary: DW_AT_LLVM_isysroot isn't useful
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: apra...@apple.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Currently an imported Clang module is represented in DWARF as
DW_TAG_module
... other atributes ...
DW_AT_LLVM_isysroot ("/Applications/Xcode.app/.../MacOSX10.15.sdk")
While the sysroot is one of the factors necessary to import a
module in the debugger, in its current form this isn't
particularly useful. First, the sysroot is a property of the
compile unit, not the module, so storing it in all DW_TAG_module DIEs
is redundant. Further, like the resource directory, it will often
be in a different location on the machine where the debugger is
compared to the machine the program was built with. We could work
around this problem by using -fdebug-prefix-map, but I think I
have an even more elegant solution:
To make it more useful, I'm proposing to
1. move DW_AT_LLVM_isysroot to DW_TAG_compile_unit and
2. on Darwin, augment it with a new attribute
DW_AT_LLVM_sdk ("MacOSX10.15.sdk")
3. rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot
(the "i" is an artifact of the command line interface)
4. Use -fdebug-prefix-map to replace all occurrences of the
sysroot and resource directory with a placeholder,
e.g., "$CLANG_SYSROOT" and "$CLANG_RESOURCEDIR". Perhaps this
can even be on by default.
This will allow LLDB to find a matching SDK on the machine it
runs on without hardcoding a path to it.
After these steps, the debug info will look like:
DW_TAG_compile_unit
... other atributes ...
DW_AT_LLVM_sdk ("MacOSX10.15.sdk")
DW_AT_LLVM_sysroot ("${CLANG_SYSROOT}")
DW_TAG_module
... other atributes ...
DW_AT_name ("Darwin")
DW_AT_LLVM_include_path ("${CLANG_SYSROOT}/usr/include")
which will make both remote debuggers and people interested in reproducible
builds happy.
--
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 44130] Merge 57776f71fa32 to fix lld build on Windows/MinGW
https://bugs.llvm.org/show_bug.cgi?id=44130 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|57776f7 |57776f7 0a64fe5 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Tom Stellard --- Merged: 0a64fe5 -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 44130, which changed state. Bug 44130 Summary: Merge 57776f71fa32 to fix lld build on Windows/MinGW https://bugs.llvm.org/show_bug.cgi?id=44130 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 44214] New: Please default to disable_coredump=1 on linux
https://bugs.llvm.org/show_bug.cgi?id=44214 Bug ID: 44214 Summary: Please default to disable_coredump=1 on linux Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: asan Assignee: unassignedb...@nondot.org Reporter: raf...@espindo.la CC: llvm-bugs@lists.llvm.org Since use_madv_dontdump defaults to true, I don't see the reason why programs compiled with asan need to be a special case with regards to dumping core. It is a bit surprising to change ulimit, run a program that crashes and still not get any core file. -- 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 42541] PowerPC integrated as - missing instructions mulldo, addo and subfo
https://bugs.llvm.org/show_bug.cgi?id=42541 Tom Stellard changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|fdf3d17 |fdf3d17 ed3f33f --- Comment #11 from Tom Stellard --- Merged: ed3f33f -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 42541, which changed state. Bug 42541 Summary: PowerPC integrated as - missing instructions mulldo, addo and subfo https://bugs.llvm.org/show_bug.cgi?id=42541 What|Removed |Added Status|REOPENED|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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 44183, which changed state. Bug 44183 Summary: Clang 9 abort trap when building mesa drivers on FreeBSD https://bugs.llvm.org/show_bug.cgi?id=44183 What|Removed |Added Status|REOPENED|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 44183] Clang 9 abort trap when building mesa drivers on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=44183 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED Fixed By Commit(s)|241cbf2 |241cbf2 52ac914 --- Comment #17 from Tom Stellard --- Merged: 52ac914 -- 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 44174] A range of ScopeRecord does not match the code enclosed by __try
https://bugs.llvm.org/show_bug.cgi?id=44174 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||r...@google.com --- Comment #1 from Reid Kleckner --- This is currently working-as-designed, and documented: https://clang.llvm.org/docs/MSVCCompatibility.html "Asynchronous Exceptions (SEH): Partial. Structured exceptions (__try / __except / __finally) mostly work on x86 and x64. LLVM does not model asynchronous exceptions, so it is currently impossible to catch an asynchronous exception generated in the same frame as the catching __try." It was brought up recently and (hopefully) clarified here: http://lists.llvm.org/pipermail/llvm-dev/2019-November/136701.html "the important thing to understand is that LLVM is currently incapable of representing non-call instructions that might throw an exception." There may be some future effort to implement support for non-call exceptions, but to my knowledge, nobody has started and there is no timeline. We have an ancient issue open covering this feature which this is arguably a duplicate of, but the discussion is somewhat stale. At some point we might wish to close it and open a new issue with a fresh design. *** This bug has been marked as a duplicate of bug 1269 *** -- 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 44215] New: D70157 "align branches within 32-Byte boundary" patch hangs on small assembly example
https://bugs.llvm.org/show_bug.cgi?id=44215 Bug ID: 44215 Summary: D70157 "align branches within 32-Byte boundary" patch hangs on small assembly example Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: fedor.v.serg...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 22888 --> https://bugs.llvm.org/attachment.cgi?id=22888&action=edit hang-mc.s I have been playing with https://reviews.llvm.org/D70157 patch and found a problem with it. It hangs in MCAssembler somewhere in vicinity of the new code. ] cd llvm-upstream/builds/release-assert ] bin/llvm-mc -x86-branches-within-32B-boundaries=true hang-mc.s -filetype=obj -o /dev/null when interrupting in debugger I get this backtrace: #0 0x74d43a5a in getFixedValue(llvm::MCMachineDependentFragment const*) () from llvm-upstream/builds/release-assert/bin/../lib/libLLVM-10git.so #1 0x74d43cef in llvm::MCAssembler::relaxMachineDependent(llvm::MCAsmLayout&, llvm::MCMachineDependentFragment&) () from llvm-upstream/builds/release-assert/bin/../lib/libLLVM-10git.so #2 0x74d445aa in llvm::MCAssembler::layoutSectionOnce(llvm::MCAsmLayout&, llvm::MCSection&) () from llvm-upstream/builds/release-assert/bin/../lib/libLLVM-10git.so #3 0x74d446fa in llvm::MCAssembler::layoutOnce(llvm::MCAsmLayout&) () from llvm-upstream/builds/release-assert/bin/../lib/libLLVM-10git.so #4 0x74d42a1b in llvm::MCAssembler::layout(llvm::MCAsmLayout&) () from llvm-upstream/builds/release-assert/bin/../lib/libLLVM-10git.so #5 0x74d4336e in llvm::MCAssembler::Finish() () from .llvm-upstream/builds/release-assert/bin/../lib/libLLVM-10git.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 44205] [Microsoft ABI] dllexport not sufficient to emit complete destructor
https://bugs.llvm.org/show_bug.cgi?id=44205 Reid Kleckner changed: What|Removed |Added Fixed By Commit(s)||705a6aef350246c790ff8e73864 ||dd27a640c59c8 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Reid Kleckner --- Should be fixed by 705a6aef350246c790ff8e73864dd27a640c59c8. I hesitate to merge it to 9.0.1. Let's save it for 10 so it receives more testing. -- 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 44216] New: objc_direct attribute seems broken with invocations from Objective-C++ classes
https://bugs.llvm.org/show_bug.cgi?id=44216 Bug ID: 44216 Summary: objc_direct attribute seems broken with invocations from Objective-C++ classes Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: i...@liuliu.me CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk I am experimenting with this attribute from commit: https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1 I am on trunk 705a6aef350246c790ff8e73864dd27a640c59c8 Adding direct in property attribute to ordinary objc class with callsites from C++ side seems cause issues. Attached project exhibit this. Also attached crash stacktraces and clang diagnostic package. ``` Process: clang-10 [60115] Path: /Users/USER/*/clang-10 Identifier:clang-10 Version: 10.0.0 (10.0) Code Type: X86-64 (Native) Parent Process:clang-10 [60113] Responsible: clang-10 [60115] User ID: 502 Date/Time: 2019-12-03 16:26:05.160 -0800 OS Version:Mac OS X 10.14.6 (18G1012) Report Version:12 Bridge OS Version: 3.0 (14Y906) Anonymous UUID:C4F0532E-C439-4C6E-B87B-991B4A18BF64 Sleep/Wake UUID: D3B480F3-43E7-4383-8517-C594956F4391 Time Awake Since Boot: 19 seconds Time Since Wake: 21000 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0030 Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Segmentation fault: 11 Termination Reason:Namespace SIGNAL, Code 0xb Terminating Process: exc handler [60115] VM Regions Near 0x30: --> __TEXT 00010c38a000-000110e3a000 [ 74.7M] r-x/r-x SM=COW /Users/USER/* Application Specific Information: Stack dump: 0. Program arguments: /Users/liuliu/Snapchat/Dev/llvm-project/build/bin/clang-10 -cc1 -triple x86_64-apple-ios10.0.0-simulator -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name SCTestDocObjectsBuilders.mm -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=all -masm-verbose -munwind-tables -target-sdk-version=13.2 -target-cpu core2 -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -target-linker-version 520 -resource-dir /Users/liuliu/Snapchat/Dev/llvm-project/build/lib/clang/10.0.0 -dependency-file buck-out/gen/Apps/ClangBugReportDemo/ClangBugReportDemoBinary#compile-SCTestDocObjectsBuilders.mm.of70b8a92,iphonesimulator-x86_64/ClangBugReportDemo/SCTestDocObjectsBuilders.mm.o.dep -MT buck-out/gen/Apps/ClangBugReportDemo/ClangBugReportDemoBinary\#compile-SCTestDocObjectsBuilders.mm.of70b8a92,iphonesimulator-x86_64/ClangBugReportDemo/SCTestDocObjectsBuilders.mm.o -sys-header-deps -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk -iquote /Users/liuliu/Snapchat/Dev/phantom -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk -iquote /Users/liuliu/Snapchat/Dev/phantom -I buck-out/gen/Apps/ClangBugReportDemo/ClangBugReportDemoBinary#iphonesimulator-x86_64,private-headers.hmap -I buck-out -D OBJC_OLD_DISPATCH_PROTOTYPES=0 -D DEBUG -D SHAKE_TO_REPORT -D SHOTGUN_INTERNAL -D USE_HOCKEY -D SC_CREMA_SERVER_ENABLED -stdlib=libc++ -internal-isystem /Users/liuliu/Snapchat/Dev/llvm-project/build/bin/../include/c++/v1 -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/c++/v1 -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/local/include -internal-isystem /Users/liuliu/Snapchat/Dev/llvm-project/build/lib/clang/10.0.0/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include -O0 -Werror -Wno-nonportable-include-path -Wno-block-capture-autoreleasing -Wno-unknown-warning-option -Wshorten-64-to-32 -Wall -Wextra -Wno-delete-non-virtual-dtor -Wno-unknown-pragmas -Wno-char-subscripts -Wno-missing-braces -Wno-reorder -Wno-overloaded-virtual -Wno-unused-property-ivar -Wno-unused-local-typedef -Wno-ignored-qualifiers -Wno-sign-compare -Wno-unused-parameter -Wno-missing-field-initializers -Wno-nullability-completeness -std=
[llvm-bugs] Issue 19228 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in clang::CXXRecordDecl::data
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-High Reported-2019-12-04 Type: Bug-Security New issue 19228 by ClusterFuzz-External: llvm:clang-fuzzer: Segv on unknown address in clang::CXXRecordDecl::data https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19228 Detailed Report: https://oss-fuzz.com/testcase?key=5673340807413760 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Segv on unknown address Crash Address: Crash State: clang::CXXRecordDecl::data getDefaultInitValue EvaluateVarDecl Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201911200438:201911230451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5673340807413760 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44215] D70157 "align branches within 32-Byte boundary" patch hangs on small assembly example
https://bugs.llvm.org/show_bug.cgi?id=44215 Fedor Sergeev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Fedor Sergeev --- Fixed with the most recent update to D70157: https://reviews.llvm.org/D70157?id=232032 -- 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
