[llvm-bugs] [Bug 34318] New: pretty-printed pointer-to-member-function types include inferred '__attribute__((thiscall))' when targeting MSVC
https://bugs.llvm.org/show_bug.cgi?id=34318 Bug ID: 34318 Summary: pretty-printed pointer-to-member-function types include inferred '__attribute__((thiscall))' when targeting MSVC Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: llvm-bugs@lists.llvm.org, r...@google.com Example: struct A; void (A::*f)() = 5; ... produces: error: cannot initialize a variable of type 'void (A::*)() __attribute__((thiscall))' with an rvalue of type 'int' Note the inferred "__attribute__((thiscall))" is included in the type name. It should not be; we should be printing the type as written. -- 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 34317] New: wasm32-unknown-unknown-wasm target generated invalid code
https://bugs.llvm.org/show_bug.cgi?id=34317
Bug ID: 34317
Summary: wasm32-unknown-unknown-wasm target generated invalid
code
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: s...@chromium.org
CC: llvm-bugs@lists.llvm.org
For the following C problems the wasm32-unknown-unknown-wasm generates invalid
wasm in that it includes an extra get_local which means that that type stack is
not empty when the function returns:
```
int main()
{
int c = 1;
asm(""::"r"(c));
return 0;
}
```
With wasm32-unknown-unknown-wasm:
43 :
47: 41 01 | i32.const 1
49: 21 00 | set_local 0
4b: 20 00 | get_local 0
4d: 41 00 | i32.const 0
4f: 0b | end
With wasm32-unknown-unknown-elf:
34 func[0]:
38: 41 01 | i32.const 1
3a: 21 00 | set_local 0
3c: 41 00 | i32.const 0
3e: 0b | end
The result of running the back code in wasm-interp is:
error: type stack at end of function is 1, expected 0
04d: error: EndFunctionBody callback failed
--
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 33972] allocator_oom_test fails on AArch64
https://bugs.llvm.org/show_bug.cgi?id=33972 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hans Wennborg --- (In reply to Hans Wennborg from comment #5) > Trying disabling the test for arm & aarch64 here: r311674 And the bot seemed happy about that: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/2396 Merged to 5.0 in r311736. -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33972, which changed state. Bug 33972 Summary: allocator_oom_test fails on AArch64 https://bugs.llvm.org/show_bug.cgi?id=33972 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33851, which changed state. Bug 33851 Summary: update .abilist files for 5.0 https://bugs.llvm.org/show_bug.cgi?id=33851 What|Removed |Added Status|ASSIGNED|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 33851] update .abilist files for 5.0
https://bugs.llvm.org/show_bug.cgi?id=33851 Eric Fiselier changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Eric Fiselier --- r311735. So sorry for being so unresponsive. -- 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 34228] Optimizer doesn't eliminate select with two equivalent operands
https://bugs.llvm.org/show_bug.cgi?id=34228 Davide Italiano changed: 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34228] Optimizer doesn't eliminate select with two equivalent operands
https://bugs.llvm.org/show_bug.cgi?id=34228 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 34316] New: fix word duplication in AST matcher reference
https://bugs.llvm.org/show_bug.cgi?id=34316 Bug ID: 34316 Summary: fix word duplication in AST matcher reference Product: Documentation Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: d...@cubic.org CC: llvm-bugs@lists.llvm.org Created attachment 19038 --> https://bugs.llvm.org/attachment.cgi?id=19038&action=edit fix to docs/LibASTMatchersReference.html See the attached diff for the fix. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34314] New: improve support for fuzz targets in LLVM
https://bugs.llvm.org/show_bug.cgi?id=34314 Bug ID: 34314 Summary: improve support for fuzz targets in LLVM Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: masc...@google.com Reporter: k...@google.com CC: ekarpen...@apple.com, llvm-b...@justinbogner.com, llvm-bugs@lists.llvm.org Currently, we have only one way to build fuzz targets (e.g. clang-fuzzer) in LLVM: specify -DLLVM_USE_SANITIZE_COVERAGE=On and -DLLVM_USE_SANITIZER=Address I would like to have this be more flexible. 1. Fuzz targets should be built in the default configuration (no asan, no coverage). They won't be suitable for fuzzing this way, but this will ensure that the code still builds (fuzz targets need to be build during check-all) 2. [stretch] each fuzz target foo-fuzz needs to have a build rule check-foo-fuzz that will execute the fuzz target on a fixed set of inputs (from the same repo) as a way of regression testing. This will ensure that the fuzz target not only builds, but runs. This is also a great regression test. 3. Fuzz targets should work with any of the sanitizers, or with none at all (-DLLVM_USE_SANITIZER=Address should not be mandatory) 4. There should be a way to specify the compile-time coverage instrumentation flags and link-time fuzzing engine flag. In particular, I'd like to support the env. vars. defined by OSS-Fuzz: CC, CXX, CFLAGS, CXXFLAGS, LIB_FUZZING_ENGINE (by passing these flags to cmake variables). This way we'll be able to build the fuzz targets with e.g. AFL, hoggfuzz, and with Clang Coverage (for coverage visualization) -- 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 34313] New: Unswitching does not catch opportunity with -fexperimental-new-pass-manager
https://bugs.llvm.org/show_bug.cgi?id=34313
Bug ID: 34313
Summary: Unswitching does not catch opportunity with
-fexperimental-new-pass-manager
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: chandl...@gmail.com
Reporter: stef...@ca.ibm.com
CC: llvm-bugs@lists.llvm.org
With the following test code:
int has_utf8 = 1;
const char AA[] = {
0, 1, 2, 3, 156, 9, 134, 17
};
int main() {
long i, count=0, num=22;
for (i=0; i<1; i++) {
num = i % 7;
if (!has_utf8 && AA[num] < 0x4)
count+=AA[num+1];
}
return count;
}
we can move the "if (!has_utf8)" outside of the loop and not run the loop at
all when has_utf8 = 1.
The opportunity is caught correctly with the old pass manager but not with the
new one.
Found with these options:
-m64 -mcpu=power8 -O3
Not found with these ones:
-m64 -mcpu=power8 -O3 -fexperimental-new-pass-manager
I did try the new unswitching pass from this patch:
https://reviews.llvm.org/D34200
but the compiler still did not find the opportunity.
--
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 23214] [META] Using LLD as FreeBSD's system linker
https://bugs.llvm.org/show_bug.cgi?id=23214 Bug 23214 depends on bug 34311, which changed state. Bug 34311 Summary: Improve -O argument handling https://bugs.llvm.org/show_bug.cgi?id=34311 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 34311] Improve -O argument handling
https://bugs.llvm.org/show_bug.cgi?id=34311 Rui Ueyama changed: What|Removed |Added CC||r...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rui Ueyama --- Addressed in r311681 and r311682. -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 34137, which changed state. Bug 34137 Summary: clang crash in llvm::SelectionDAG::Combine on -O0 https://bugs.llvm.org/show_bug.cgi?id=34137 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 34137] clang crash in llvm::SelectionDAG::Combine on -O0
https://bugs.llvm.org/show_bug.cgi?id=34137 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Hans Wennborg --- (In reply to Hans Wennborg from comment #6) > Dmitry: is your test case randomly generated, or reduced from a real-world > test case? > > Nirav's patch landed in r311623. Let's see how that does on trunk. Merged in r311670. -- 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 34312] New: Clang's source locations are too detailed for Visual Studio, breaking "step into specific"
https://bugs.llvm.org/show_bug.cgi?id=34312
Bug ID: 34312
Summary: Clang's source locations are too detailed for Visual
Studio, breaking "step into specific"
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Blocks: 28154
Discovered by a Chromium developer: http://crbug.com/756175
The summary is that MSVC emits statement line information, not expression line
information. Consider this example:
/* 1 */ int g(int a, int b, int c, int d, int e, int f) {
/* 2 */ return a + b + c + d + e + f;
/* 3 */ }
/* 4 */ int x() { return 1; }
/* 5 */ int main() {
/* 6 */ return g(
/* 7 */ x(),
/* 8 */ x(),
/* 9 */ x(),
/* 10 */ x(),
/* 11 */ x(),
/* 12 */ x()
/* 13 */ );
/* 14 */ }
When compiled by clang (clang-cl -Z7 step.c), MS debuggers step through this
program by stopping at line 5, 12, 11, 10, 9, 8, 7, 6, and 14. When compiled
with MSVC, windbg and VS will stop on lines 5, 6, and 14.
In fact, you cannot break on lines 7-12 when debugging an MSVC binary. It will
only stop at the beginning of the statement. Perhaps to work around that
limitation, VS has a feature called "step into specific"
(https://msdn.microsoft.com/en-us/library/7ad07721(v=vs.100).aspx):
"""
To step into a specific function
1. Advance the execution point to the function call you want to step into. You
might use a breakpoint, Step Into, Step Over, or Run To Cursor.
2. Right-click the source window.
3. Click Step Into Specific and choose the function you want.
The debugger executes the function call and breaks at the beginning of the
selected function. The Step Into Specific command appears only if the execution
point is located on a line of code that contains a nested function.
"""
This feature only works when the function call you want to step into is within
the same line table entry, so all expressions within the same statement must
have the same location information in order for it to work.
The downside of implementing this is that it will reduce the accuracy of line
info in stack traces. Clang's line tables in my example will be able to
distinguish which call to x is on the stack, while MSVC's will not. We already
have -gcolumn-info, which essentially improves stack trace quality at the cost
of more confusing stepping behavior in the debugger, so I think we should make
this new behavior conditional on -gcodeview && !-gcolumn-info.
I suspect we can add the check to disable location information inside
`ApplyDebugLocation(CodeGenFunction &CGF, const Expr *E)`, and then we can
modify CGStmt.cpp to apply debug locations when emitting statements.
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=28154
[Bug 28154] [meta] Add support for CodeView, the MSVC-compatible debug
information format
--
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 34311] New: Improve -O argument handling
https://bugs.llvm.org/show_bug.cgi?id=34311 Bug ID: 34311 Summary: Improve -O argument handling Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Blocks: 23214 I am currently working through the build failures found in a FreeBSD ports build using lld as the linker. A few ports are failing due to differences in treatment of the -O option. 1. -O with no argument Although not documented, ld.bfd accepts -O without an argument. Example invocation: % ld.bfd -O string-lib.o -x -r string-lib.o % Because -O is documented as taking a number it seems reasonable to reject an invocation with no argument. Our error message could be improved though: % ld.lld -O ld.lld: error: -O: number expected, but got Even "number expected, but got ''" as produced by parseInt (vs getInteger) is a bit more clear. 2. Space before argument Linking is sometimes performed with something like -Wl,-O,2 passed to the compiler driver, resulting in % ld.bfd -O 2 string-lib.o -x -r string-lib.o -O should just be JoinedOrSeparate perhaps? Example failing ports: archivers/lua51-zlib, www/cgihtml Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=23214 [Bug 23214] [META] Using LLD as FreeBSD's system linker -- 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 34310] New: libc++ does not correctly handle the regex: "[^\\W]
https://bugs.llvm.org/show_bug.cgi?id=34310
Bug ID: 34310
Summary: libc++ does not correctly handle the regex: "[^\\W]
Product: libc++
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: alex.seme...@samsung.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
I find bug in libc++ in regex. This is my code sample:
#include
#include
#include
int main() {
std::string HW("HelloWorld");
std::regex RE("[^\\W]");
if (std::regex_search(HW, RE))
std::cout << "regexp is OK";
else
std::cout << "regexp is broken";
std::cout << std::endl;
return 0;
}
This is my command for compilation:
clang++ -std=c++11 -stdlib=libc++ main.cpp
And I get:
regexp is broken
But, if I use libstdc++ :
clang++ -std=c++11 -stdlib=libstdc++ main.cpp
It's ok:
regexp is OK
I get bug only for regexp [^\\W] and for combinations with it.
I use libc++dev form ubuntu version: 3.9.1-2
--
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 34309] New: Assertion failure in clang::ento::MemRegionManager::getElementRegion()
https://bugs.llvm.org/show_bug.cgi?id=34309
Bug ID: 34309
Summary: Assertion failure in
clang::ento::MemRegionManager::getElementRegion()
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: ale...@google.com
CC: llvm-bugs@lists.llvm.org
$ cat /tmp/getElementRegion-crash.cc
struct {
int *n;
bool f(unsigned &p1) { p1 = (long)n - 1; }
} b;
unsigned a;
int c;
void g() { b.f(a) && a == c; }
$ clang_tidy -checks=-*,clang-analyzer-* /tmp/getElementRegion-crash.cc --
-std=c++11
assert.h assertion failed at llvm/tools/clang/include/clang/AST/Type.h:628 in
const clang::ExtQualsTypeCommonBase *clang::QualType::getCommonPtr() const:
!isNull() && "Cannot retrieve a NULL type pointer"
@ 0x53f0f5a __assert_fail
@ 0x5e9065 clang::QualType::getCommonPtr()
@ 0x5ddbe9 clang::QualType::getCanonicalType()
@ 0x1b4f5cc clang::ASTContext::getCanonicalType()
@ 0x2c50612 clang::ento::MemRegionManager::getElementRegion()
@ 0x2d07f58 (anonymous
namespace)::SimpleSValBuilder::evalBinOpLN()
@ 0x2bbbace clang::ento::SValBuilder::evalBinOp()
@ 0x2d09ab4 (anonymous
namespace)::SimpleSValBuilder::simplifySVal()::Simplifier::VisitSymIntExpr()
@ 0x2d09692 clang::ento::SymExprVisitor<>::Visit()
@ 0x2d093ea (anonymous
namespace)::SimpleSValBuilder::simplifySVal()::Simplifier::VisitNonLocSymbolVal()
@ 0x2d08f6b clang::ento::SValVisitor<>::Visit()
@ 0x2d0822f (anonymous
namespace)::SimpleSValBuilder::simplifySVal()
@ 0x2d056cc (anonymous
namespace)::SimpleSValBuilder::evalBinOpNN()
@ 0x2bbbd92 clang::ento::SValBuilder::evalBinOp()
@ 0x2cab136 clang::ento::ExprEngine::evalBinOp()
@ 0x2cd8320 clang::ento::ExprEngine::VisitBinaryOperator()
@ 0x2ca0a91 clang::ento::ExprEngine::Visit()
@ 0x2c9dea4 clang::ento::ExprEngine::ProcessStmt()
@ 0x2c9db6a clang::ento::ExprEngine::processCFGElement()
@ 0x2ccb526 clang::ento::CoreEngine::HandlePostStmt()
@ 0x2ccae23 clang::ento::CoreEngine::dispatchWorkItem()
@ 0x2cca9b8 clang::ento::CoreEngine::ExecuteWorkList()
@ 0x21227d5 clang::ento::ExprEngine::ExecuteWorkList()
@ 0x20cb182 (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@ 0x20caf41 (anonymous
namespace)::AnalysisConsumer::RunPathSensitiveChecks()
@ 0x20cac05 (anonymous namespace)::AnalysisConsumer::HandleCode()
@ 0x20be323 (anonymous
namespace)::AnalysisConsumer::HandleDeclsCallGraph()
@ 0x20bc5a7 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
@ 0x29d335e clang::MultiplexConsumer::HandleTranslationUnit()
--
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 34308] New: many files rebuilt after adding empty commit to llvm repo (cmake + ninja)
https://bugs.llvm.org/show_bug.cgi?id=34308 Bug ID: 34308 Summary: many files rebuilt after adding empty commit to llvm repo (cmake + ninja) Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: matthias.krue...@famsik.de CC: llvm-bugs@lists.llvm.org This looks like the worse brother of #33717 . My setup consists of llvm, clang, clang-tools-extra, compiler-rt, polly, lld, lldb and openmp repos. Using cmake and ninja to build only the targets clang LLVMgold llvm-ar llvm-ranlib lld and afterwards check-llvm check-clang check-lld. I noticed that ninja would always rebuild ~1900 files even if only a single cpp file changed after the last pull. Upon investigating, it turned out that an empty commit (git commit --allow-empty) in the llvm repo is enough to make ninja rebuilt hundreds of files. :/ However doing consecutive build without file changes/commits works fine and ninja continues where it was last stopped. My full bootstrap script can be found here: https://github.com/matthiaskrgr/llvm_bootstrap/blob/master/build_git.sh -- 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 34307] New: [5.0.0-rc2] clang-cl assertion during incorrect command line in response file
https://bugs.llvm.org/show_bug.cgi?id=34307 Bug ID: 34307 Summary: [5.0.0-rc2] clang-cl assertion during incorrect command line in response file Product: clang Version: 5.0 Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: egor.pu...@gmail.com CC: llvm-bugs@lists.llvm.org Create 1.rsp file with contents (2 lines): "-Xclang" "-nostdinc" Run: clang-cl @1.rsp Assertion failed: Index >= End && "Unexpected parser error.", file C:\src\llvm_package_500_rc2\llvm\lib\Option\OptTable.cpp, line 337 Wrote crash dump file "C:\Users\egorp\AppData\Local\Temp\clang-cl.exe-76118e.dmp" 0x7FF7E34F7056 (0x0001 0x005CF618E330 0x0151 0x7FFDB4A3AF61) 0x7FFDB4A927A7 (0x0001 0x7FF7 0x 0x005CF618E300), raise() + 0x1E7 bytes(s) 0x7FFDB4A934A1 (0x00020003 0x0003 0x7FFDB4AE54D0 0x7FF7E5F7E0B8), abort() + 0x31 bytes(s) 0x7FFDB4A95202 (0x02268A663010 0x0007 0x7FF7E6096AF0 0x0151), _get_wpgmptr() + 0x1CA2 bytes(s) 0x7FFDB4A950FD (0x0151 0x7FF7E5F7E0B8 0x 0x0005), _get_wpgmptr() + 0x1B9D bytes(s) 0x7FFDB4A9543F (0x 0x7FF7E5271FFC 0x005CF618EDC8 0x7FF7E5271FFC), _wassert() + 0x3F bytes(s) 0x7FF7E3358747 (0x0002 0x02268A642E80 0x7FFDB4AD48EC 0x) 0x7FF7E1D1370E (0x 0x 0x 0x) 0x7FF7E526E781 (0x 0x 0x 0x) 0x7FFDB5B72774 (0x 0x 0x 0x), BaseThreadInitThunk() + 0x14 bytes(s) 0x7FFDB8320D51 (0x 0x 0x 0x), RtlUserThreadStart() + 0x21 bytes(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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34306] New: Odd PC rel for thread local
https://bugs.llvm.org/show_bug.cgi?id=34306
Bug ID: 34306
Summary: Odd PC rel for thread local
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: c...@remobjects.com
CC: llvm-bugs@lists.llvm.org
With latest llvm/lld on Win32 (link flavor) I get an odd PC rel for thread
local statics:
_GetCurrent:
402000: 55 pushl %ebp
402001: 89 e5 movl%esp, %ebp
402003: e8 00 00 00 00 calll 0 <_GetCurrent+0x8>
402008: 58 popl%eax
402009: 8b 88 00 10 40 00 movl4198400(%eax), %ecx
40200f: 64 8b 80 2c 00 00 00movl%fs:44(%eax), %eax
402016: 8b 04 88movl(%eax,%ecx,4), %eax
402019: 8b 80 00 00 00 00 movl(%eax), %eax
40201f: 5d popl%ebp
402020: c3 retl
notice 402009, which does a movl 4198400 (_tls_index)%eax, %ecx, where %eax is
PC, this crashes here and I'm having trouble seeing how this would ever work
since 4198400 is already the real address.
Steps:
- llvm-as.exe isl.out.ll
- lld.exe -flavor link isl.out.bc /entry:main /debug /opt:lldlto=0 /force
then disassemble it.
(Note that /force is only here for testcase purposes, it fails in a full
project without /force too)
Code:
; ModuleID = 'isl.out'
source_filename = "Island"
target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i686-pc-windows-msvc"
module asm ".globl _tls_array\0D"
module asm "_tls_array = 44\0D"
module asm ".globl __tls_array\0D"
module asm "__tls_array = 44"
@_tls_index = global i32 0
@fCurrent = thread_local global i8* null
define i8* @GetCurrent() #0 {
br label %1
; :1: ; preds = %0
%2 = load i8*, i8** @fCurrent
ret i8* %2
}
declare void @DoSomething(i8*)
define void @main() {
%1 = call i8* @GetCurrent()
call void @DoSomething(i8* %1)
ret void
}
attributes #0 = { "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" }
--
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 34106] ARMTargetLowering::isLegalAddressingMode can accept incorrect addressing modes for Thumb1 target
https://bugs.llvm.org/show_bug.cgi?id=34106 Evgeny Astigeevich changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|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
