[llvm-bugs] [Bug 33031] Cannot scavenge register without an emergency spill slot!
https://bugs.llvm.org/show_bug.cgi?id=33031 kristof.be...@arm.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from kristof.be...@arm.com --- Fixed in r304196. -- 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 33220] New: Exception handling bug with mingw-w64
https://bugs.llvm.org/show_bug.cgi?id=33220
Bug ID: 33220
Summary: Exception handling bug with mingw-w64
Product: new-bugs
Version: 4.0
Hardware: PC
OS: other
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: svyatoslav.scherb...@jetbrains.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18533
--> https://bugs.llvm.org/attachment.cgi?id=18533&action=edit
test
$ cat bug.cpp
class Foo {
public:
~Foo() {}
};
void __attribute__((noinline)) bar() {
Foo foo;
throw 42;
}
int main() {
try {
bar();
} catch (int x) {
}
return 0;
}
The attached program doesn't run right if compiled by clang++ with '-O2' for
x86_64-w64-mingw32 (tested with mingw-w64 6.3.0).
The program abnormally terminates instead of catching the exception:
$ clang++ -O2 -target x86_64-w64-mingw32 bug.cpp && ./a.exe
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'int'
The bug seems to be triggered by the function 'bar' which has personality
function '__gxx_personality_seh0' specified but doesn't have any landingpad
after the optimization:
___
; Function Attrs: noinline noreturn uwtable
define void @_Z3barv() local_unnamed_addr #0 personality i8* bitcast (i32
(...)* @__gxx_personality_seh0 to i8*) {
entry:
%exception = tail call i8* @__cxa_allocate_exception(i64 4) #3
%0 = bitcast i8* %exception to i32*
store i32 42, i32* %0, align 16, !tbaa !2
tail call void @__cxa_throw(i8* %exception, i8* bitcast (i8** @_ZTIi to i8*),
i8* null) #4
unreachable
}
___
--
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 33221] New: [UBSAN] segfault with -fsanitize=undefined
https://bugs.llvm.org/show_bug.cgi?id=33221
Bug ID: 33221
Summary: [UBSAN] segfault with -fsanitize=undefined
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: d.khali...@partner.samsung.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18534
--> https://bugs.llvm.org/attachment.cgi?id=18534&action=edit
ubsan fix for vptr check
Hello everyone.
I have a situation when UBSAN got segfault.
Test case (that code actually close example of the code in package
groff-1.22.3.)
$cat test.cc
class Base {
public:
Base *next;
virtual void print() {}
};
class Derived : public Base {
public:
void print() {}
};
enum { SIZE = 2 };
int main() {
Derived *list = (Derived *)new char[SIZE * sizeof(Derived)];
list->next = list + 1;
return 0;
}
$clang++ -o test test.cc -fsanitize=undefined -fsanitize=address
$./test
And we will get following backtrace:
==3737==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x0051a9f2 bp 0x00531bf8 sp 0x7ffc38852540 T0)
==3737==The signal is caused by a READ memory access.
==3737==Hint: address points to the zero page.
#0 0x51a9f1 in getVtablePrefix
/llvm/projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:200
#1 0x51a9f1 in __ubsan::checkDynamicType(void*, void*, unsigned long)
/llvm/projects/compiler-rt/lib/ubsan/ubsan_type_hash_itanium.cc:223
#2 0x518942 in
HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long,
unsigned long, __ubsan::ReportOptions)
/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:37
#3 0x519232 in __ubsan_handle_dynamic_type_cache_miss
/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:87
#4 0x51addd in main (/test/ubsan/test+0x51addd)
#5 0x7ff8cad7ef44 in __libc_start_main
/build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:287
#6 0x41ac9b in _start (/test/ubsan/test+0x41ac9b)
As far as I understood vptr is initializing by constructor of the object. In
this code that doesn't happen, this code use operator new () of type char which
doesn't have default constructor. Standard says:
if default constructor is not specified
(7.3) no initialization is performed.
So, vptr could have a junk data, at the beginning of the object, which
cause a segfault in function getVtablePrefix.
Should we check Vptr with
if (!IsAccessibleMemoryRange((uptr)Vptr, sizeof(VtablePrefix)))
instead
if (!Vptr)
I've attached patch for this issue.
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 33154] inconsistent formatting of javascript function braces
https://bugs.llvm.org/show_bug.cgi?id=33154 Martin Probst changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Martin Probst --- I took a look. The problem is that detecting an automatic semicolon on "} (ident|statement)" throws off the indentation counting. I'll mark this as WONTFIX for now, it'd require substantial refactoring of how clang-format handles indentation. I'd recommend using a JS linter (jslint, tslint, ...) to detect missing semis, and fixing them manually. -- 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 32496, which changed state. Bug 32496 Summary: Merge r294264 into the 4.0 branch : [LVI] Switch from BFS to DFS exploration order https://bugs.llvm.org/show_bug.cgi?id=32496 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 32496] Merge r294264 into the 4.0 branch : [LVI] Switch from BFS to DFS exploration order
https://bugs.llvm.org/show_bug.cgi?id=32496 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Tom Stellard --- Based on code owner feedback, I think this is a little too risky to merge. -- 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 33223] New: cxa_demangle failes for inherited constructors
https://bugs.llvm.org/show_bug.cgi?id=33223
Bug ID: 33223
Summary: cxa_demangle failes for inherited constructors
Product: libc++abi
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: tbergham...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
libc++abi fails to demangle the mangled name generated by clang for an
inherited constructor.
Example name where cxa_demangle fails: _ZN5bCI25aEi
Source code for generating the mangled name:
class a {
public:
a(int);
};
class b : a {
using a::a;
};
void c() { b(1); }
Clang version used to generate the name:
clang version 5.0.0 (trunk 303332) (llvm/trunk 303340)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Additional context:
https://bugs.llvm.org/show_bug.cgi?id=33177
http://sourcerytools.com/pipermail/cxx-abi-dev/2016-May/002918.html
Open question: What should be the output of __cxa_demangle when demangling an
inherited constructor? What do people think about "b::b(int)" (hides
that it is an inherited constructor) or "b::a(int)" (hides that it is a
constructor) for the above case?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33180] OpenCL r303986 broke all ARM bots
https://bugs.llvm.org/show_bug.cgi?id=33180 Anastasia Stulova changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Anastasia Stulova --- Fixed by https://reviews.llvm.org/rL304191 -- 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 33224] New: clang places implicitly declared C functions at compile unit scope
https://bugs.llvm.org/show_bug.cgi?id=33224
Bug ID: 33224
Summary: clang places implicitly declared C functions at
compile unit scope
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: momchil.veli...@arm.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18537
--> https://bugs.llvm.org/attachment.cgi?id=18537&action=edit
testcase
Compiling the following testcase with `clang -std=c90 -c x.c`
> int f() {
>g();
>return 0;
> }
>
> int (*p)() = g;
completes successfully.
The identifier `g` is not declared at the place, where it appears in the
context of the function call expression. In that case, the C90 Standard says
(6.3.3.2 Function calls):
> If the expression that precedes the parenthesized argument list in a
> function
> call consists solely by an identifier, and if no declaration is visible
> for this
> identifier, the identifier is implicitly declared as if, in the innermost
> block
> containing the function call, the declaration
>
> extern int identifier();
>
> appeared.
Therefore, the above program should be equivalent to:
> int f() {
>extern int g();
>g();
>return 0;
> }
>
> int (*p)() = g;
for which clang terminates with an error. The C90 Standard (6.1.2.1 Scopes of
identifiers), says:
> If the declarator or type specifier that declared the identifier appears
> inside a block [...],
> the identifier has block scope, which terminates at the } that closes the
> associated block.
so, this should be the correct behavior in both testcases.
However, clang places the implicitly declared function at translation
unit scope, which causes the identifier to be visible in the initializer
in the original testcase, in effect accepting an invalid program.
--
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 30384] r280609: Host.cpp fails to build using Xcode 4.6.3: use of undeclared identifier '__get_cpuid_max'
https://bugs.llvm.org/show_bug.cgi?id=30384 Alina Sbirlea changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alina Sbirlea --- The fix revision stayed in. Marking as 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 33225] New: Lops with memcpy suffer from poor LSR treatment on SystemZ.
https://bugs.llvm.org/show_bug.cgi?id=33225 Bug ID: 33225 Summary: Lops with memcpy suffer from poor LSR treatment on SystemZ. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 18538 --> https://bugs.llvm.org/attachment.cgi?id=18538&action=edit reduced testcase This is the same issue as with vector load / store: only a 12 bit displacement is supported with MVC, which implements the memcpy. I tried to extend LSR to treat this the same way as with a Load or Store, but that does not work, since it seems that a memcpy Fixup does not get any Offset, but it is rather the Formula (of type Basic) which has an UnfoldedOffset. I tried then with @@ -1290,6 +1290,11 @@ void Cost::RateFormula(const TargetTransformInfo &TTI, if ((isa(Fixup.UserInst) || isa(Fixup.UserInst)) && !TTI.isFoldableMemAccessOffset(Fixup.UserInst, Offset)) NumBaseAdds++; + +if (Offset == 0 && F.UnfoldedOffset != 0 && +isa(Fixup.UserInst) && +!TTI.isFoldableMemAccessOffset(Fixup.UserInst, F.UnfoldedOffset)) + NumBaseAdds++; , but this did only handle a very few cases. It did add the right cost, but it seemed that there was no other formula to be rated higher. It turns out that even though this was a fairly small single-block loop containing basically 8 memcpy calls, the EstimateSearchSpaceComplexity() still return a too high value, so the formulas with the foldable offsets unfortunately got pruned. The loop becomes: .LBB0_2:# %for.body75 # =>This Inner Loop Header: Depth=1 lay%r3, -4096(%r1) mvc0(48,%r1), 0(%r3) lay%r3, -288(%r2) mvc0(48,%r3), 0 lay%r3, -240(%r2) mvc0(48,%r3), 0 lay%r3, -192(%r2) mvc0(48,%r3), 0 lay%r3, -144(%r2) mvc0(48,%r3), 0(%r1) mvc0(48), 0 mvc0(48), 0 mvc0(48,%r2), 0 lay%r1, 8192(%r1) la%r2, 384(%r2) j.LBB0_2 with another heuristic for narrowing the search space (-lsr-exp-narrow), it seems the better formula is still there: .LBB0_2:# %for.body75 # =>This Inner Loop Header: Depth=1 lay%r3, -4096(%r2) mvc0(48,%r1), 0(%r3) mvc0(48,%r1), 0 mvc0(48,%r1), 0 mvc0(48,%r1), 0 mvc0(48,%r1), 0(%r2) mvc0(48), 0 mvc0(48), 0 mvc0(48,%r1), 0 lay%r2, 8192(%r2) la%r1, 384(%r1) j.LBB0_2 This actually works even without my little patch per above. Comparing -lsr-exp-narrow across SPEC, it increases the total number of load-adress instructions (unfolded offsets), with or without my patch, so it does not seem good to just switch generally. Is there any possibility of squeezing in the offset heuristic somewhere in this pruning process? Is there anything else here that I missed? Run reduced test case with llc -O3 -mtriple=s390x-linux-gnu -mcpu=z13 ./tc_mvcs.ll llc -O3 -mtriple=s390x-linux-gnu -mcpu=z13 ./tc_mvcs.ll -lsr-exp-narrow -- 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 32200, which changed state. Bug 32200 Summary: Failed test on 4.0 Release Candidate 4 https://bugs.llvm.org/show_bug.cgi?id=32200 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32200] Failed test on 4.0 Release Candidate 4
https://bugs.llvm.org/show_bug.cgi?id=32200 Tom Stellard changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Tom Stellard --- Merged: r304213 -- 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 33101, which changed state. Bug 33101 Summary: Merge r296485 into the 4.0 branch: Driver: Update devtoolset usage for RHEL https://bugs.llvm.org/show_bug.cgi?id=33101 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 33101] Merge r296485 into the 4.0 branch: Driver: Update devtoolset usage for RHEL
https://bugs.llvm.org/show_bug.cgi?id=33101 Tom Stellard changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #2 from Tom Stellard --- We did some more testing on this and we found a bug that requires an additional patch to fix, so we'll leave this out of 4.0.1. -- 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 33226] New: [coroutines] ICE "Pass 'Coroutine Elision' is not initialized" with -fcoroutines-ts -O0
https://bugs.llvm.org/show_bug.cgi?id=33226 Bug ID: 33226 Summary: [coroutines] ICE "Pass 'Coroutine Elision' is not initialized" with -fcoroutines-ts -O0 Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: enieb...@boost.org CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Repro steps (with trunk latest on a Mac): > mkdir ~/llvm-build > cd ~/llvm-build # -DLLVM_TARGETS_TO_BUILD='X86' seems to matter here: > cmake -DCMAKE_INSTALL_PREFIX:PATH=~/llvm-install > -DCMAKE_BUILD_TYPE:STRING=Release -DLLVM_TARGETS_TO_BUILD='X86' ~/llvm > make && make install # Any empty input file will do > echo // comment > test.cpp > ~/llvm-install/bin/clang++ -fcoroutines-ts -O0 -c test.cpp Result: eniebler-mbp:llvm-ninja eniebler$ ~/llvm-install/bin/clang++ -fcoroutines-ts -O0 -c test.cpp Pass 'Coroutine Elision' is not initialized. Verify if there is a pass dependency cycle. Required Passes: 0 clang-5.00x00010ac06808 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 clang-5.00x00010ac06e76 SignalHandler(int) + 342 2 libsystem_platform.dylib 0x7fffbca5eb3a _sigtramp + 26 3 clang-5.00x00010c8f3ba8 (anonymous namespace)::DarwinX86AsmBackend::getCompactUnwindRegNum(unsigned int) const::CU64BitRegs + 132176 4 clang-5.00x00010b432c54 addCoroutineOpt0Passes(llvm::PassManagerBuilder const&, llvm::legacy::PassManagerBase&) + 52 5 clang-5.00x00010a82a573 llvm::PassManagerBuilder::addExtensionsToPM(llvm::PassManagerBuilder::ExtensionPointTy, llvm::legacy::PassManagerBase&) const + 307 6 clang-5.00x00010a82b4a2 llvm::PassManagerBuilder::populateModulePassManager(llvm::legacy::PassManagerBase&) + 770 7 clang-5.00x00010adafc53 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr >) + 13123 8 clang-5.00x00010af580c9 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 889 9 clang-5.00x00010b7e7405 clang::ParseAST(clang::Sema&, bool, bool) + 469 10 clang-5.00x00010b1788a3 clang::FrontendAction::Execute() + 67 11 clang-5.00x00010b1366e8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1080 12 clang-5.00x00010b1bb1de clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 5326 13 clang-5.00x00010a094cfc cc1_main(llvm::ArrayRef, char const*, void*) + 1196 14 clang-5.00x00010a093b60 main + 12096 15 libdyld.dylib0x7fffbc84f235 start + 1 Stack dump: 0. Program arguments: /Users/eniebler/llvm-install/bin/clang-5.0 -cc1 -triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 274.1 -dwarf-column-info -debugger-tuning=lldb -coverage-notes-file /Users/eniebler/llvm-ninja/test.gcno -resource-dir /Users/eniebler/llvm-install/lib/clang/5.0.0 -stdlib=libc++ -O0 -fdeprecated-macro -fdebug-compilation-dir /Users/eniebler/llvm-ninja -ferror-limit 19 -fmessage-length 247 -stack-protector 1 -fblocks -fcoroutines-ts -fobjc-runtime=macosx-10.12.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cpp 1. parser at end of file clang-5.0: error: unable to execute command: Segmentation fault: 11 clang-5.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 5.0.0 (http://llvm.org/git/clang.git 1c50ce32c7bb476416a210cfbcbb5e934c266538) (http://llvm.org/git/llvm.git f0c3d71794d1695efe08bdf83c6b1824dcf07c80) Target: x86_64-apple-darwin16.5.0 Thread model: posix InstalledDir: /Users/eniebler/llvm-install/bin clang-5.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-5.0: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-5.0: note: diagnostic msg: /var/folders/0_/77jy5prn181b5wn2xzl1cbfc18wy7r/T/test-a028ed.cpp clang-5.0: note: diagnostic msg: /var/folders/0_/77jy5prn181b5wn2xzl1c
[llvm-bugs] [Bug 33227] New: Defect with llvm::reverse used in for loop with a comparison
https://bugs.llvm.org/show_bug.cgi?id=33227 Bug ID: 33227 Summary: Defect with llvm::reverse used in for loop with a comparison Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: colse...@hotmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18539 --> https://bugs.llvm.org/attachment.cgi?id=18539&action=edit Example std::vector V(10); for (unsigned I : Fwd ? V : llvm::reverse(V)) llvm::errs() << I << "\n"; In this example compilation succeeds without even a warning but failure occurs when Fwd is true. -- 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 33065] false(?) -Wsequence warning
https://bugs.llvm.org/show_bug.cgi?id=33065 Stephen Hines changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #10 from Stephen Hines --- Moving this back to Resolved/Invalid. Unfortunately, the C and C++ Standards Committees don't always see eye-to-eye on every potential related issue. This is one such example. I have no evidence that Clang is leveraging the ordering of these arguments to do something different in C vs. C++ today, but that doesn't prevent them from doing something like that in the future. The right thing is to fix your code based on the warning, since the warning does complain exactly about what the C standard requires here. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 12416] MachineInstr verifier fails
https://bugs.llvm.org/show_bug.cgi?id=12416 Matthias Braun changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||ma...@braunis.de --- Comment #3 from Matthias Braun --- I changed the machine verifier checks in 2015 to make it legal for a register use to only have parts of its values live, so this shouldn't abort 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 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS
https://bugs.llvm.org/show_bug.cgi?id=32146 Bug 32146 depends on bug 12416, which changed state. Bug 12416 Summary: MachineInstr verifier fails https://bugs.llvm.org/show_bug.cgi?id=12416 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 33228] New: new llvm::sys::fs::is_local_impl(statvfs&)' is toxic to Solaris build
https://bugs.llvm.org/show_bug.cgi?id=33228 Bug ID: 33228 Summary: new llvm::sys::fs::is_local_impl(statvfs&)' is toxic to Solaris build Product: libraries Version: trunk Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: fedor.serg...@oracle.com CC: llvm-bugs@lists.llvm.org After updating to the trunk from release_40 branch my x86-Solaris-11 build starts failing: = [ 0%] Built target LLVMDemangle [ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o In file included from /LLVM/llvm-50/llvm/lib/Support/Path.cpp:1220:0: /LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc: In function 'bool llvm::sys::fs::is_local_impl(statvfs&)': /LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc:103:35: error: 'struct statvfs' has no member named 'f_flags' #define STATVFS_F_FLAG(vfs) (vfs).f_flags ^ /LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc:385:13: note: in expansion of macro 'STATVFS_F_FLAG' return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL); ^ /fsergeev/LLVM/llvm-50/llvm/lib/Support/Unix/Path.inc:385:35: error: 'MNT_LOCAL' was not declared in this scope return !!(STATVFS_F_FLAG(Vfs) & MNT_LOCAL); ^ gmake[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Path.cpp.o] Error 1 gmake[1]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/all] Error 2 gmake: *** [all] Error 2 = Obviously statvfs usage is not compatible with Solaris interfaces. -- 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 33174] Merge r298177 into the 4.0 branch : [X86] Add NumRegisterParameters Module Flag.
https://bugs.llvm.org/show_bug.cgi?id=33174 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Stellard --- Merged: r304238 -- 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 33174, which changed state. Bug 33174 Summary: Merge r298177 into the 4.0 branch : [X86] Add NumRegisterParameters Module Flag. https://bugs.llvm.org/show_bug.cgi?id=33174 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 32797, which changed state. Bug 32797 Summary: Merge r293630 into the 4.0 branch : [cmake] Support running tests in stand-alone builds https://bugs.llvm.org/show_bug.cgi?id=32797 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 33174] Merge r298177 into the 4.0 branch : [X86] Add NumRegisterParameters Module Flag.
https://bugs.llvm.org/show_bug.cgi?id=33174 Tom Stellard changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Tom Stellard --- Accidentally updated the wrong bug, r304238 is the merge commit from a different bug. -- 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 32797] Merge r293630 into the 4.0 branch : [cmake] Support running tests in stand-alone builds
https://bugs.llvm.org/show_bug.cgi?id=32797 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tom Stellard --- Merged: r304238 -- 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 33174, which changed state. Bug 33174 Summary: Merge r298177 into the 4.0 branch : [X86] Add NumRegisterParameters Module Flag. https://bugs.llvm.org/show_bug.cgi?id=33174 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 27307] clang-cl rejects -fno-delayed-template-parsing
https://bugs.llvm.org/show_bug.cgi?id=27307 Stephan T. Lavavej changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Stephan T. Lavavej --- Works in Clang/LLVM 4.0: C:\Temp>clang-cl /EHsc /nologo /W4 -fno-ms-compatibility meow.cpp && meow Microsoft one-phase! C:\Temp>clang-cl /EHsc /nologo /W4 -fno-ms-compatibility -fno-delayed-template-parsing meow.cpp && meow Standard two-phase! -- 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 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 33170, which changed state. Bug 33170 Summary: Merge r298179 into the 4.0 branch : Make library calls sensitive to regparm module flag (Fixes PR3997). https://bugs.llvm.org/show_bug.cgi?id=33170 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 33170] Merge r298179 into the 4.0 branch : Make library calls sensitive to regparm module flag (Fixes PR3997).
https://bugs.llvm.org/show_bug.cgi?id=33170 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom Stellard --- Merged: r304242 -- 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 33229] New: llvm.addcarry is incorrectly lowered
https://bugs.llvm.org/show_bug.cgi?id=33229
Bug ID: 33229
Summary: llvm.addcarry is incorrectly lowered
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: deadal...@gmail.com, fil...@gmail.com,
llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk,
simon.f.whitta...@gmail.com,
warren_ris...@playstation.sony.com
Based on a report from Warren Ristow:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define i32 @tinkywinky() {
entry:
%0 = tail call i8 @llvm.x86.addcarry.u64(i8 0, i64 0, i64 0, i8* null)
ret i32 0
}
declare i8 @llvm.x86.addcarry.u64(i8, i64, i64, i8*)
$ ./llc carry.ll
Value type is non-standard value, Other.
UNREACHABLE executed at ../include/llvm/CodeGen/MachineValueType.h:623!
#0 0x01dbc95a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(./llc+0x1dbc95a)
#1 0x01dba74e llvm::sys::RunSignalHandlers() (./llc+0x1dba74e)
#2 0x01dba89c SignalHandler(int) (./llc+0x1dba89c)
#3 0x7f2f9be1ec30 __restore_rt (/lib64/libpthread.so.0+0x10c30)
#4 0x7f2f9a98a765 __GI_raise (/lib64/libc.so.6+0x34765)
#5 0x7f2f9a98c36a __GI_abort (/lib64/libc.so.6+0x3636a)
#6 0x01d606aa (./llc+0x1d606aa)
#7 0x00813ce8 llvm::MVT::getSizeInBits() const (./llc+0x813ce8)
#8 0x01c61615 llvm::SelectionDAG::getConstant(unsigned long,
llvm::SDLoc const&, llvm::EVT, bool, bool) (./llc+0x1c61615)
#9 0x0120f858 llvm::X86TargetLowering::PerformDAGCombine(llvm::SDNode*,
llvm::TargetLowering::DAGCombinerInfo&) const (./llc+0x120f858)
#10 0x01ba7d69 (anonymous
namespace)::DAGCombiner::combine(llvm::SDNode*) (./llc+0x1ba7d69)
#11 0x01ba9560 (anonymous
namespace)::DAGCombiner::Run(llvm::CombineLevel) (./llc+0x1ba9560)
#12 0x01bab9ac llvm::SelectionDAG::Combine(llvm::CombineLevel,
llvm::AAResults*, llvm::CodeGenOpt::Level) (./llc+0x1bab9ac)
#13 0x01c7f1aa llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(./llc+0x1c7f1aa)
#14 0x01c89821
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(./llc+0x1c89821)
#15 0x01c8b810
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone
.part.805] (./llc+0x1c8b810)
#16 0x0115f624 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(./llc+0x115f624)
#17 0x015b3705
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (./llc+0x15b3705)
#18 0x0189e073 llvm::FPPassManager::runOnFunction(llvm::Function&)
(./llc+0x189e073)
#19 0x0189e134 llvm::FPPassManager::runOnModule(llvm::Module&)
(./llc+0x189e134)
#20 0x0189eda1 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(./llc+0x189eda1)
#21 0x007ce8b5 compileModule(char**, llvm::LLVMContext&)
(./llc+0x7ce8b5)
#22 0x0075fd58 main (./llc+0x75fd58)
#23 0x7f2f9a976731 __libc_start_main (/lib64/libc.so.6+0x20731)
#24 0x007c20e9 _start (./llc+0x7c20e9)
Stack dump:
0. Program arguments: ./llc carry.ll
1. Running pass 'Function Pass Manager' on module 'carry.ll'.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function
'@tinkywinky'
--
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 33230] New: Clang on Windows should define __STDCPP_THREADS__ to be 1
https://bugs.llvm.org/show_bug.cgi?id=33230
Bug ID: 33230
Summary: Clang on Windows should define __STDCPP_THREADS__ to
be 1
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18541
--> https://bugs.llvm.org/attachment.cgi?id=18541&action=edit
Self-contained test case
C:\Temp>type meow.cpp
/***
N4659 19.8 [cpp.predefined]/2:
"The following macro names are conditionally defined by the implementation:
[...]
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if
a program can have more than one thread of execution (4.7)."
***/
#ifdef __STDCPP_THREADS__
#if __STDCPP_THREADS__ == 1
#include
int main() { puts("Success!"); }
#else
#error WOOF
#endif
#else
#error BOOM
#endif
C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Temp>cl /EHsc /nologo /W4 meow.cpp && meow
meow.cpp
Success!
C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin
C:\Temp>clang-cl /EHsc /nologo /W4 meow.cpp && meow
meow.cpp(17,6): error: BOOM
#error BOOM
^
1 error generated.
C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp(17,6): error: BOOM
#error BOOM
^
1 error generated.
--
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 33231] New: poor handling of io errors?
https://bugs.llvm.org/show_bug.cgi?id=33231
Bug ID: 33231
Summary: poor handling of io errors?
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: matthias.krue...@famsik.de
CC: llvm-bugs@lists.llvm.org
lld @ 3710f10def28ec96b20b86dea048f9f11260734e /
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@304206
91177308-0d34-0410-b5e6-96231b3b80d8
I was doing a 2 stage (first stage optimized for performance, seconds stage:)
cmake ../llvm -G "Ninja" \
-DCMAKE_BUILD_TYPE="Debug" \
-DLLVM_BINUTILS_INCDIR=/usr/include \
-DCMAKE_C_FLAGS="-march=native -Og -g3" \
-DCMAKE_CXX_FLAGS="-march=native -Og -g3" \
-DLLVM_OPTIMIZED_TABLEGEN=1 \
-DCMAKE_AR="${rootDir}/stage_1/build/bin/llvm-ar" \
-DCMAKE_RANLIB="${rootDir}/stage_1/build/bin/llvm-ranlib" \
-DLLVM_USE_LINKER="${rootDir}/stage_1/build/bin/ld.lld" \
-DLLVM_USE_SANITIZER="Address;Undefined" \
-DLLVM_PARALLEL_LINK_JOBS=1 \
-DLLVM_ENABLE_EXPENSIVE_CHECKS=1 \
build.
Everything went well until it came to linking the clang-5.0 binary.
After approximately one hour and 30 minutes, lld was still hogging disk IO
seemingly, (most of the time, there were around 10-20 megabyte/s read and a
fews kilobyte/s write here and there) and I killed the process.
There was close to no cpu consumption by lld and the clang binary was staying
at around 1.2 gigabyte of size.
It looked like lld hung. Unfortunately I killed it and didn't think about
attaching gdb. :(
Later I discovered that SMART disk monitoring threw some errors:
May 30 22:25:56 t420 smartd[1277]: Device: /dev/sda [SAT], 32 Currently
unreadable (pending) sectors
May 30 22:25:56 t420 smartd[1277]: Device: /dev/sda [SAT], 32 Offline
uncorrectable sectors
I wonder if lld hung because of these disk errors.
Does lld handle such errors gracefully?
--
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 33232] New: Clang should report that char[] is NOT trivially destructible
https://bugs.llvm.org/show_bug.cgi?id=33232
Bug ID: 33232
Summary: Clang should report that char[] is NOT trivially
destructible
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18542
--> https://bugs.llvm.org/attachment.cgi?id=18542&action=edit
Self-contained test case
For historical (TR1-era) reasons, MSVC's STL implements
std::is_trivially_destructible with __has_trivial_destructor(). We do so
directly, with no additional logic, so we expect this builtin to follow the
Standard's specification exactly. C1XX provides such behavior, but Clang
doesn't.
If it were absolutely necessary, we could change MSVC's STL to implement
std::is_trivially_destructible with an __is_trivially_destructible builtin, but
then Clang would have to implement that - and it would be a headache for other
reasons.
C:\Temp>type meow.cpp
/***
N4659 23.15.4.3 [meta.unary.prop]:
Template: template struct is_destructible;
Condition: Either T is a reference type, or T is a complete object type for
which the expression
declval().~U() is well-formed when treated as an unevaluated operand
(Clause 8),
where U is remove_all_extents.
Preconditions: T shall be a complete type, cv void, or an array of unknown
bound.
Template: template struct is_trivially_destructible;
Condition: is_destructible_v is true and the indicated destructor is known
to be trivial.
Preconditions: T shall be a complete type, cv void, or an array of unknown
bound.
Template: template struct is_nothrow_destructible;
Condition: is_destructible_v is true and the indicated destructor is known
not to throw any exceptions (8.3.7).
Preconditions: T shall be a complete type, cv void, or an array of unknown
bound.
***/
template struct is_destructible {
static constexpr bool value = __is_destructible(T);
};
template struct is_trivially_destructible {
static constexpr bool value = __has_trivial_destructor(T);
};
template struct is_nothrow_destructible {
static constexpr bool value = __is_nothrow_destructible(T);
};
int main() {
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value, "BOOM");
static_assert(!is_trivially_destructible::value,
"BOOM");
static_assert(!is_nothrow_destructible::value, "BOOM");
static_assert(!is_nothrow_destructible::value, "BOOM");
static_assert(!is_nothrow_destructible::value, "BOOM");
static_assert(!is_nothrow_destructible::value,
"BOOM");
}
C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Temp>cl /EHsc /nologo /W4 meow.cpp
meow.cpp
C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin
C:\Temp>clang-cl /EHsc /nologo /W4 meow.cpp
meow.cpp(37,5): error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value, "BOOM");
^ ~
meow.cpp(38,5): error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value, "BOOM");
^ ~~~
meow.cpp(39,5): error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value, "BOOM");
^ ~~
meow.cpp(40,5): error: static_assert failed "BOOM"
static_assert(!is_trivially_destructible::value,
"BOOM");
^
4 errors generated.
--
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 33233] New: [x86] Failing to tail-call memcpy and memmove due to extern C
https://bugs.llvm.org/show_bug.cgi?id=33233
Bug ID: 33233
Summary: [x86] Failing to tail-call memcpy and memmove due to
extern C
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: llvm-bugs@lists.llvm.org
Blocks: 26299
For the following code, we're failing to generate tail calls:
#include
void* libc_memcpy(void* dest, const void* src, size_t n) {
return memcpy(dest, src, n);
}
void* libc_memmove(void* dest, const void* src, size_t n) {
return memmove(dest, src, n);
}
$ bin/clang -target i686-unknown-linux-gnu -S -O3 -o - /tmp/a.cc
.text
.file "/tmp/a.cc"
.globl _Z11libc_memcpyPvPKvj # -- Begin function
_Z11libc_memcpyPvPKvj
.p2align4, 0x90
.type _Z11libc_memcpyPvPKvj,@function
_Z11libc_memcpyPvPKvj: # @_Z11libc_memcpyPvPKvj
# BB#0: # %entry
pushl %esi
subl$8, %esp
movl16(%esp), %esi
subl$4, %esp
pushl 28(%esp)
pushl 28(%esp)
pushl %esi
calll memcpy
addl$16, %esp
movl%esi, %eax
addl$8, %esp
popl%esi
retl
[snip]
Pretty horrible. Without the header:
#include
extern "C" {
void* memcpy(void* dest, const void* src, size_t n);
void* memmove(void* dest, const void* src, size_t n);
}
void* libc_memcpy(void* dest, const void* src, size_t n) {
return memcpy(dest, src, n);
}
void* libc_memmove(void* dest, const void* src, size_t n) {
return memmove(dest, src, n);
}
Same thing.
But, if I remove the extern "C":
#include
void* memcpy(void* dest, const void* src, size_t n);
void* memmove(void* dest, const void* src, size_t n);
void* libc_memcpy(void* dest, const void* src, size_t n) {
return memcpy(dest, src, n);
}
void* libc_memmove(void* dest, const void* src, size_t n) {
return memmove(dest, src, n);
}
$ bin/clang -target i686-unknown-linux-gnu -S -O3 -o - /tmp/a.cc
.text
.file "/tmp/a.cc"
.globl _Z11libc_memcpyPvPKvj # -- Begin function
_Z11libc_memcpyPvPKvj
.p2align4, 0x90
.type _Z11libc_memcpyPvPKvj,@function
_Z11libc_memcpyPvPKvj: # @_Z11libc_memcpyPvPKvj
.cfi_startproc
# BB#0: # %entry
jmp _Z6memcpyPvPKvj # TAILCALL
.Lfunc_end0:
[snip]
Beautiful!
Why does extern "C" matter here?
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=26299
[Bug 26299] [meta][X86] Size optimization opportunities (in particular for
32-bit Chromium on Windows)
--
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 33234] New: LLVM misses loadpre opportunities
https://bugs.llvm.org/show_bug.cgi?id=33234
Bug ID: 33234
Summary: LLVM misses loadpre opportunities
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: daniel...@gmail.com
CC: llvm-bugs@lists.llvm.org
#cat t.cc
void foo(int *p, int t, int *a, int *b, int *c) {
for (int i = 0; i < t; i++) {
if (a[i]) {
*p += b[i];
} else {
*p *= c[i];
}
}
}
#clang -O2 -S t.cc -fno-unroll-loops
testl %esi, %esi
jle .LBB0_6
# BB#1:
movl%esi, %eax
.p2align4, 0x90
.LBB0_2:# =>This Inner Loop Header: Depth=1
cmpl$0, (%rdx)
je .LBB0_4
# BB#3: # in Loop: Header=BB0_2 Depth=1
movl(%rdi), %esi
addl(%rcx), %esi
jmp .LBB0_5
.p2align4, 0x90
.LBB0_4:# in Loop: Header=BB0_2 Depth=1
movl(%rdi), %esi
imull (%r8), %esi
.LBB0_5:# in Loop: Header=BB0_2 Depth=1
movl%esi, (%rdi)
addq$4, %rdx
addq$4, %rcx
addq$4, %r8
decq%rax
jne .LBB0_2
.LBB0_6:
retq
#gcc -O2 -S t.cc -fno-unroll-loops
testl %esi, %esi
jle .L1
movl(%rdi), %r9d
xorl%eax, %eax
jmp .L5
.p2align 4,,10
.p2align 3
.L9:
addl(%rcx,%rax,4), %r9d
addq$1, %rax
movl%r9d, (%rdi)
cmpl%eax, %esi
jle .L1
.L5:
movl(%rdx,%rax,4), %r10d
testl %r10d, %r10d
jne .L9
imull (%r8,%rax,4), %r9d
addq$1, %rax
movl%r9d, (%rdi)
cmpl%eax, %esi
jg .L5
.L1:
rep
ret
For the gcc version, there are only 2 loads + 1 store each iteration. For llvm
version, there are 3 loads + 1 store each iteration.
The problem is that llvm failed to move the load of *p outside of the loop.
--
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 33235] New: clang-cl doesn't treat __declspec(nothrow) as noexcept; fails to compile
https://bugs.llvm.org/show_bug.cgi?id=33235
Bug ID: 33235
Summary: clang-cl doesn't treat __declspec(nothrow) as
noexcept; fails to compile
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18543
--> https://bugs.llvm.org/attachment.cgi?id=18543&action=edit
Self-contained test case
C:\Temp>type meow.cpp
struct Base {
__declspec(nothrow) Base() { }
};
struct Derived : Base {
Derived() noexcept = default;
};
int main() { }
C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Temp>cl /EHsc /nologo /W4 /std:c++latest meow.cpp
meow.cpp
C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin
C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp
meow.cpp(6,5): error: exception specification of explicitly defaulted default
constructor does not match the calculated one
Derived() noexcept = default;
^
1 error generated.
--
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 33236] New: clang-cl emits bogus error: cannot decompose this type; 'std::tuple_size::value' is not a valid integral constant expression
https://bugs.llvm.org/show_bug.cgi?id=33236
Bug ID: 33236
Summary: clang-cl emits bogus error: cannot decompose this
type; 'std::tuple_size::value' is not a valid
integral constant expression
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18545
--> https://bugs.llvm.org/attachment.cgi?id=18545&action=edit
Self-contained test case
Note: This is using my implementation of LWG 2770 tuple_size SFINAE, which will
ship in VS 2017's first toolset update (aka "15.3").
C:\Temp>type meow.cpp
#include
#include
struct S {
int x;
};
int main() {
S s{99};
auto [m1] = s;
auto& [r1] = s;
assert(m1 == 99);
assert(&r1 == &s.x);
const S cs{1729};
auto [m2] = cs;
auto& [r2] = cs;
assert(m2 == 1729);
assert(&r2 == &cs.x);
}
C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Temp>cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp
C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin
C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp(17,11): error: cannot decompose this type; 'std::tuple_size::value' is not a valid integral constant expression
auto& [r2] = cs;
^
1 error generated.
I believe that this is the same issue as what I reported to the reflectors on
April 3, 2017. C1XX has implemented my preferred resolution.
--
Subject: [isocpp-lib] New issue - Core and Library disagree on tuple_size
SFINAE (LWG 2770)
LWG 2770's resolution taught tuple_size to SFINAE. However, Core's wording for
structured bindings disagrees with what the Library provides.
N4659 23.5.3.6 [tuple.helper]/4: "template class tuple_size;
template class tuple_size; template class
tuple_size; Let TS denote tuple_size of the cv-unqualified
type T. If the expression TS::value is well-formed when treated as an
unevaluated operand, then each of the three templates shall meet the
UnaryTypeTrait requirements (23.15.1) with a base characteristic of
integral_constant Otherwise, they shall have no member
value."
When the Library provides SFINAE, Meow is complete, it's just that
Meow::value or Meow::type is non-existent. This is the
long-standing practice followed by invoke_result, etc.
However, Core expects different behavior:
11.5 [dcl.struct.bind]/3: "Otherwise, if the qualified-id std::tuple_size
names a complete type, the expression std::tuple_size::value shall be a
well-formed integral constant expression and"
This wording was introduced in Issaquah as the resolution of GB 20 (thanks to
Casey for the programmer-archaeology). He found no discussion, just "ready for
vote on Friday".
I encountered this because I implemented tuple_size SFINAE with the traditional
approach (it is a complete class with no members), yet libc++ had a test
expecting tuple_size to be an incomplete class. I argue that the
Core wording should change - it should not inspect the completeness of
tuple_size, but should instead inspect the well-formedness of
tuple_size::value, which is what the Library is already doing when
implementing tuple_size.
Thanks,
STL
--
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 32608] Post RA scheduler incorrectly renames callee saved register
https://bugs.llvm.org/show_bug.cgi?id=32608 Carrot changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Carrot --- This is fixed by r304001. -- 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 33237] New: clang-cl: Ignore or implement /diagnostics:caret, /Zc:ternary, and (on x64) /Gr and /Gz
https://bugs.llvm.org/show_bug.cgi?id=33237
Bug ID: 33237
Summary: clang-cl: Ignore or implement /diagnostics:caret,
/Zc:ternary, and (on x64) /Gr and /Gz
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18546
--> https://bugs.llvm.org/attachment.cgi?id=18546&action=edit
Hello World
This behavior isn't the end of the world, but it makes it harder to
simultaneously use cl.exe and clang-cl.exe for testing.
C:\Temp>type meow.cpp
#include
int main() {
puts("Cute fluffy kittens!");
}
C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Temp>cl /EHsc /nologo /W4 meow.cpp
meow.cpp
C:\Temp>cl /EHsc /nologo /W4 /diagnostics:caret meow.cpp
meow.cpp
C:\Temp>cl /EHsc /nologo /W4 /Zc:ternary meow.cpp
meow.cpp
C:\Temp>cl /EHsc /nologo /W4 /Gr meow.cpp
meow.cpp
C:\Temp>cl /EHsc /nologo /W4 /Gz meow.cpp
meow.cpp
C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin
C:\Temp>clang-cl /EHsc /nologo /W4 meow.cpp
C:\Temp>clang-cl /EHsc /nologo /W4 /diagnostics:caret meow.cpp
clang-cl.exe: error: no such file or directory: '/diagnostics:caret'
C:\Temp>clang-cl /EHsc /nologo /W4 /Zc:ternary meow.cpp
clang-cl.exe: warning: argument unused during compilation: '/Zc:ternary'
[-Wunused-command-line-argument]
C:\Temp>clang-cl /EHsc /nologo /W4 /Gr meow.cpp
error: invalid argument '-fdefault-calling-conv=' not allowed with
'x86_64-pc-windows-msvc19.11.25326'
C:\Temp>clang-cl /EHsc /nologo /W4 /Gz meow.cpp
error: invalid argument '-fdefault-calling-conv=' not allowed with
'x86_64-pc-windows-msvc19.11.25326'
--
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 33238] New: Wrong isl ast schedule generated
https://bugs.llvm.org/show_bug.cgi?id=33238
Bug ID: 33238
Summary: Wrong isl ast schedule generated
Product: Polly
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Other
Assignee: polly-...@googlegroups.com
Reporter: huih...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Created attachment 18547
--> https://bugs.llvm.org/attachment.cgi?id=18547&action=edit
test input
Attaching the test.ll as test input
Run command "opt -polly-codegen -S test.ll -debug"
Polly produce the isl ast schedule of:
{
if (p_0 >= 3) {
for (int c0 = 0; c0 < (p_0 + 2) / 4; c0 += 1) {
Stmt0(c0);
if (p_0 >= 4 * c0 + 3) {
Stmt2(c0);
if (p_0 >= 4 * c0 + 4) {
Stmt4(c0);
if (p_0 >= 4 * c0 + 5)
Stmt6(c0);
}
}
}
if ((p_0 - 1) % 4 == 0) {
Stmt7();
} else if (p_0 % 4 == 0) {
Stmt5();
} else if ((p_0 + 1) % 4 == 0) {
Stmt3();
}
} else {
Stmt0(0);
}
Stmt1();
}
else
{ /* original code */ }
However, the correct schedule should be:
{
if (p_0 >= 3) {
for (int c0 = 0; c0 < (p_0 + 2) / 4; c0 += 1) {
Stmt0(c0);
if (p_0 >= 4 * c0 + 3) {
Stmt2(c0);
if (p_0 >= 4 * c0 + 4) {
Stmt4(c0);
if (p_0 >= 4 * c0 + 5)
Stmt6(c0);
}
}
}
if ((p_0 - 1) % 4 == 0) {
Stmt7();
} else if (p_0 % 4 == 0) {
Stmt5();
} else if ((p_0 + 1) % 4 == 0) {
Stmt3();
}
} else {
Stmt0(0);
}
if((n <= 2) || ((n - 2)%4 == 0))
Stmt1();
}
else
{ /* original code */ }
Notice that for Statement Stmt1(), Polly produce universe domain, Stmt1 is
being executed unconditionally. However, if going through the basic blocks of
the input test.ll file, Stmt1 will only be executed under condition "((n <= 2)
|| ((n - 2)%4 == 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33185] SimplifyBinOp can make incorrect transformation in the presence of phi nodes
https://bugs.llvm.org/show_bug.cgi?id=33185 Daniel Berlin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Daniel Berlin --- r304272 (it actually turns out to be more closely related to whether we have to recursively translate ops or 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 33239] New: SHN_ABS symbols cause --gc-sections to crash
https://bugs.llvm.org/show_bug.cgi?id=33239 Bug ID: 33239 Summary: SHN_ABS symbols cause --gc-sections to crash Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: smee...@fb.com CC: compn...@compnerd.org, gri...@accesssoftek.com, llvm-bugs@lists.llvm.org, rafael.espind...@gmail.com, r...@google.com % touch empty.bin % ld.lld -m elf_x86_64 -b binary --relocatable -o empty.o empty.bin % ld.lld -shared --gc-sections -o libempty.so empty.o ld.lld: ../../../include/llvm/Support/Casting.h:104: static bool llvm::isa_impl_cl::doit(const From*) [with To = lld::elf::InputSectionBase; From = lld::elf::SectionBase]: Assertion `Val && "isa<> used on a null pointer"' failed. The assertion is triggered via the cast in [1]. The symbol for which it fails is _binary_empty_bin_size, which is absolute and has a null Section. I'm using the first ld.lld command because it was how I came across the issue; I believe it would generalize to any SHN_ABS symbol, however. I'm not sure if there are scenarios in which a non-absolute symbol would trigger the assertion. [1] https://reviews.llvm.org/diffusion/L/browse/lld/trunk/ELF/MarkLive.cpp;304274$223?color=1 -- 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 33240] New: Enhancement request: __attribute__((warn_untested_result))
https://bugs.llvm.org/show_bug.cgi?id=33240
Bug ID: 33240
Summary: Enhancement request:
__attribute__((warn_untested_result))
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: j...@perches.com
CC: llvm-bugs@lists.llvm.org
Duplicate request submitted to gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80522
A possibly useful addition similar to:
__attribute__((warn_unused_result))
might be
__attribute__((warn_untested_result))
for things like allocation failures that
are not verified before use.
For instance:
void *malloc(size_t size);
could become
void * __attribute__((warn_untested_result)) malloc(size_t size)
so that
#include
struct foo {
int bar;
};
struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
baz->bar = 1;
return baz;
}
The compiler could emit a warning on the set
of baz->bar as an intermediate test of baz
is not performed before any use of baz.
struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
if (baz) baz->bar = 1;
return baz;
}
This variant would not emit a warning.
Similarly, alloc_foo could use that new attribute.
Martin Sebor also mentioned that non-allocation
functions like fopen could also use this __attribute__
mechanism.
--
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 33241] New: compiling chromium Segmentation fault
https://bugs.llvm.org/show_bug.cgi?id=33241 Bug ID: 33241 Summary: compiling chromium Segmentation fault Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: tof...@protonmail.com CC: llvm-bugs@lists.llvm.org [user@SA src]$ ninja -C out/my_build chrome ninja: Entering directory `out/my_build' [17688/28773] CXX obj/v8/v8_base/wasm-compiler.o FAILED: obj/v8/v8_base/wasm-compiler.o ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/v8/v8_base/wasm-compiler.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DDISABLE_NACL -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=\"303910-1\" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCOMPONENT_BUILD -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_GLIBCXX_DEBUG=1 -DBUILDING_V8_SHARED -DENABLE_DISASSEMBLER -DOBJECT_PRINT -DVERIFY_HEAP -DV8_TRACE_MAPS -DV8_ENABLE_CHECKS -DV8_INTL_SUPPORT -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_TARGET_ARCH_X64 -DDEBUG -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DUSING_V8_BASE_SHARED -I../.. -Igen -I../../v8 -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../v8/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -B../../third_party/binutils/Linux_x64/Release/bin -fcolor-diagnostics -m64 -march=x86-64 -pthread -Wall -Werror -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wno-unused-lambda-capture -Wno-user-defined-warnings -fno-omit-frame-pointer -g0 --sysroot=../../build/linux/debian_jessie_amd64-sysroot -fvisibility=hidden -Xclang -load -Xclang ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-auto-raw-pointer -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wsign-compare -Winconsistent-missing-override -Wshorten-64-to-32 -O3 -fno-ident -fdata-sections -ffunction-sections -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=gnu++11 -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -c ../../v8/src/compiler/wasm-compiler.cc -o obj/v8/v8_base/wasm-compiler.o #0 0x01d11124 (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1d11124) #1 0x01d11446 (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1d11446) #2 0x7ffb4e5c3c30 __restore_rt (/lib64/libpthread.so.0+0x10c30) #3 0x018c2b94 llvm::Use::getUser() const (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x18c2b94) #4 0x014c3e78 llvm::isKnownNonNullAt(llvm::Value const*, llvm::Instruction const*, llvm::DominatorTree const*) (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x14c3e78) #5 0x019bda15 (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19bda15) #6 0x019b2643 (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19b2643) #7 0x0198f14b (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x198f14b) #8 0x01990fed (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1990fed) #9 0x019915fc llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19915fc) #10 0x0188adbf llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x188adbf) #11 0x02728526 (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x2728526) #12 0x0188b515 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/user/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang+0x188b515) #13 0x01e9daeb clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendActi
[llvm-bugs] [Bug 33226] [coroutines] ICE "Pass 'Coroutine Elision' is not initialized" with -fcoroutines-ts -O0
https://bugs.llvm.org/show_bug.cgi?id=33226 gornisha...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from gornisha...@gmail.com --- Fixed: Differential Revision: https://reviews.llvm.org/D33701 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304277 91177308-0d34-0410-b5e6-96231b3b80d8 -- 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 33242] New: Address Sanitizer (ASAN) flags incorrect heap-use-after-free on PowerPC
https://bugs.llvm.org/show_bug.cgi?id=33242 Bug ID: 33242 Summary: Address Sanitizer (ASAN) flags incorrect heap-use-after-free on PowerPC Product: compiler-rt Version: 4.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: david.h...@mongodb.com CC: llvm-bugs@lists.llvm.org We are using ASAN builds within our testing infrastructure to find potential errors. Recently we have upgraded to LLVM 4.0 on our PowerPC test machine and have encountered the error below. The error is highly sporadic as we have only reproduced it twice while attempting to get to the bottom of the error. Most interesting is that the error stems from T52, which is working with a data structure that would in no way be related to that seen in T2. The data structure allocated/freed in T2 is a "WT_DICTIONARY" the item being accessed (inline) on T52 would be a "WT_INSERT" allocated elsewhere. On its face, we suspect that the issue here could be error in accounting within ASAN on PowerPC. Error as Reported: = ==40049==ERROR: AddressSanitizer: heap-use-after-free on address 0x0a1804122c18 at pc 0x1053ef84 bp 0x3fff7852b420 sp 0x3fff7852b440 READ of size 8 at 0x0a1804122c18 thread T52 #0 0x1053ef80 in __col_insert_search /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/include/column.i:189:15 #1 0x1053c2b4 in __wt_col_search /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/col_srch.c:297:18 #2 0x106c8cbc in __cursor_col_search /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/bt_cursor.c:320:2 #3 0x106d12e0 in __btcur_update /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/bt_cursor.c:1066:3 #4 0x106d273c in __wt_btcur_update /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/btree/bt_cursor.c:1167:10 #5 0x105a7e28 in __curfile_update /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/cursor/cur_file.c:293:2 #6 0x10159e44 in col_update /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/test/format/../../../test/format/ops.c:1501:16 #7 0x101513ec in ops /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/test/format/../../../test/format/ops.c:781:11 #8 0x10107658 in __asan::AsanThread::ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*) /home/dhows/downloads/llvm/projects/compiler-rt/lib/asan/asan_thread.cc:256 #9 0x1003bec8 in asan_thread_start(void*) /home/dhows/downloads/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:296 #10 0x3fff84ca8940 in start_thread (/lib64/power8/libpthread.so.0+0x8940) #11 0x3fff849f763c in __clone (/lib64/power8/libc.so.6+0x11763c) 0x0a1804122c18 is located 8 bytes inside of 24-byte region [0x0a1804122c10,0x0a1804122c28) freed by thread T2 here: #0 0x100f30ac in __interceptor_cfree.localalias.0 /home/dhows/downloads/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:55 #1 0x1028ee18 in __wt_free_int /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/os_common/os_alloc.c:311:2 #2 0x102f1018 in __rec_dictionary_free /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:6510:3 #3 0x102e89c0 in __rec_destroy /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:996:2 #4 0x102e304c in __rec_destroy_session /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:1008:2 #5 0x102cfbf0 in __wt_reconcile /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/reconcile/rec_write.c:499:3 #6 0x10218bc0 in __evict_review /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_page.c:559:8 #7 0x102162b8 in __wt_evict /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_page.c:149:2 #8 0x101fc504 in __evict_page /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_lru.c:2168:2 #9 0x101f5ae8 in __evict_lru_pages /home/jenkins/jenkins/workspace/wiredtiger-test-format-stress-sanitizer-ppc/build_posix/../src/evict/evict_lru.c:1160:14 #10 0x101f4d9c in __wt_evict_thread_run /home/jenkins/jenkins/workspace/wiredtiger-test-forma
