[llvm-bugs] [Bug 27789] Clang trunk crashes on knl target
https://llvm.org/bugs/show_bug.cgi?id=27789 igorb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from igorb --- fixed in r270357 http://reviews.llvm.org/rL270357 -- 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 27832] New: Missing handling of endianness(host) != endianess(target) in ExecutionEngine::LoadValueFromMemory
https://llvm.org/bugs/show_bug.cgi?id=27832 Bug ID: 27832 Summary: Missing handling of endianness(host) != endianess(target) in ExecutionEngine::LoadValueFromMemory Product: libraries Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Generic Execution Engine Support Assignee: unassignedb...@nondot.org Reporter: l...@christian-eichler.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16394 --> https://llvm.org/bugs/attachment.cgi?id=16394&action=edit Example .ll (big endian targetlayout) Method `ExecutionEngine::StoreValueToMemory` reverses the byte order in memory if the endianness of host and target do not match. Method `ExecutionEngine::LoadValueFromMemory` currently does not undo that operation, leading to loading of incorrect values. Running lli with the .ll file attached to this report shows different return values for `lli -force-interpreter loadstore_endian.ll` and `lli loadstore_endian.ll` when executed on a little endian system. This statement holds (at least) for lli from LLVM 3.4 up to LLVM 3.8 -- 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 27342] Segfault with function SFINAE in valid code
https://llvm.org/bugs/show_bug.cgi?id=27342 Mads Ravn changed: What|Removed |Added Status|NEW |RESOLVED CC||madsr...@gmail.com Resolution|--- |FIXED --- Comment #2 from Mads Ravn --- I compiled the code located at https://gist.github.com/jacquelinekay/ef45d875a9cfbcda1e85db27b296cf1b just fine with clang version 3.8.0. So I imagine that this bug has been resolved. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27833] New: SIMD code with -O2
https://llvm.org/bugs/show_bug.cgi?id=27833
Bug ID: 27833
Summary: SIMD code with -O2
Product: clang
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: kazunori.ueda...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16396
--> https://llvm.org/bugs/attachment.cgi?id=16396&action=edit
v2d2.i and related source files
The enclosed program, compiled with clang -m32 -O2 *.i, produces a strange
output
0x7b06e5ed, 0x7b06e44f, 0x7b06e5f5, 0x7b06e42f
0x7b06e5f5, 0x7b06e42f, 0x0, 0x0
segmentation fault: 11
from two successive printf statements in v2d2.i:
printf("%p, %p, %p, %p\n",
allocp[116], allocp[117], allocp[118], allocp[119]);
x59 = ((q)((unsigned long)(&allocp[118]) + 0x1));
printf("%p, %p, %p, %p\n",
allocp[116], allocp[117], allocp[118], allocp[119]);
while clang -m32 -O1 *.i produces an expected output
0x7c2d81ed, 0x7c2d804f, 0x7c2d81f5, 0x7c2d802f
0x7c2d81ed, 0x7c2d804f, 0x7c2d81f5, 0x7c2d802f
I look into the assembly code of v2d2.c and found that -O2 uses SIMD
instructions while -O1 doesn't.
FYI, v2d2.c is a simplified version of a machine-generated program from our
compiler, and all the other .c files are just to make v2d2.c run.
--
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 27834] New: [python binding] cindex.py should contain version information
https://llvm.org/bugs/show_bug.cgi?id=27834 Bug ID: 27834 Summary: [python binding] cindex.py should contain version information Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: steve...@gmail.com CC: kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified See for example: https://pythontips.com/2013/08/28/finding-the-module-version/ the __version__ variable could be set. -- 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 27835] New: Assertion triggered in SemaChecking.cpp
https://llvm.org/bugs/show_bug.cgi?id=27835 Bug ID: 27835 Summary: Assertion triggered in SemaChecking.cpp Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified It is observed that clang triggered assertion on lld buildbot. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-debian-fast/builds/38263/steps/build/logs/stdio clang-3.9: /home/llvmbb/llvm-buildit/llvm/tools/clang/lib/Sema/SemaChecking.cpp:5937: clang::Expr *EvalAddr(clang::Expr *, SmallVectorImpl &, clang::Decl *): Assertion `(E->getType()->isAnyPointerType() || E->getType()->isBlockPointerType() || E->getType()->isObjCQualifiedIdType()) && "EvalAddr only works on pointers"' failed. #0 0x018b9d68 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x18b9d68) #1 0x018ba4c7 SignalHandler(int) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x18ba4c7) #2 0x7fa78ad23d30 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d30) #3 0x7fa78a10e458 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x33458) #4 0x7fa78a10f8da abort (/lib/x86_64-linux-gnu/libc.so.6+0x348da) #5 0x7fa78a107387 (/lib/x86_64-linux-gnu/libc.so.6+0x2c387) #6 0x7fa78a107432 (/lib/x86_64-linux-gnu/libc.so.6+0x2c432) #7 0x026c0905 EvalAddr(clang::Expr*, llvm::SmallVectorImpl&, clang::Decl*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x26c0905) #8 0x026a65d3 clang::Sema::CheckReturnValExpr(clang::Expr*, clang::QualType, clang::SourceLocation, bool, llvm::SmallVector const*, clang::FunctionDecl const*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x26a65d3) #9 0x02a2f104 clang::Sema::BuildReturnStmt(clang::SourceLocation, clang::Expr*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x2a2f104) #10 0x02a2e919 clang::Sema::ActOnReturnStmt(clang::SourceLocation, clang::Expr*, clang::Scope*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x2a2e919) #11 0x024e5f37 clang::Parser::ParseReturnStatement() (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24e5f37) #12 0x024e1043 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24e1043) #13 0x024e0925 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24e0925) #14 0x024e7a2a clang::Parser::ParseCompoundStatementBody(bool) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24e7a2a) #15 0x024e838c clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24e838c) #16 0x0246002c clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x246002c) #17 0x024efd7e clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24efd7e) #18 0x024ee935 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24ee935) #19 0x024ee265 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24ee265) #20 0x02473594 clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x2473594) #21 0x0245ded4 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x245ded4) #22 0x0245d432 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x245d432) #23 0x024593a6 clang::ParseAST(clang::Sema&, bool, bool) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x24593a6) #24 0x01dbb045 clang::FrontendAction::Execute() (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x1dbb045) #25 0x01d86801 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/llvmbb/bin/clang-latest/bin/clang-3.9+0x1d86801) #26 0x01e51a22 clang::ExecuteCompilerInvocat
[llvm-bugs] [Bug 27836] New: Segfault of __thread varaible in Linux/ARM due to bug of LLVM ARM code generation
https://llvm.org/bugs/show_bug.cgi?id=27836 Bug ID: 27836 Summary: Segfault of __thread varaible in Linux/ARM due to bug of LLVM ARM code generation Product: libraries Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: lee...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16399 --> https://llvm.org/bugs/attachment.cgi?id=16399&action=edit ARM: don't attempt to merge litpools referencing different PC-anchors. There are four thread local storage (TLS) models in Clang/LLVM as following: 1) global-dynamic TLS model 2) local-dynamic TLS model 3) local-exec TLS model 4) initial-exec TLS model and emulated-TLS (for Android S/W platform)?? Even though, We can build run normally with the static relocation method by selecting the initial-exec TLS model instead of global-dynamic TLS model (by default) , We need to run the clang application code with global-dynamic (or local-dynamic) TLS model in order that we support some applications is working with dlopen(3) library call. We have found the appropriate solution for some clang/LLVM applications including 1) __thread variables and 2) -O2/-O3 of the clang language. Could you apply this patch to Ubuntu 14.04 LTS and Ubuntu 16.04 LTS repository? * LLVM: Revision 268662 (ARM: don't attempt to merge litpools referencing different PC-anchors.) http://llvm.org/viewvc/llvm-project?view=revision&revision=268662 Below is the mailing list discussed to fix this issue. http://lists.llvm.org/pipermail/llvm-dev/2016-May/098974.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160502/353476.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/355091.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356679.html * Before r268662: ubuntu@raspberrypi2#> ./corerun ./hello.exe (with -O2/-O3) Segmentation Fault * After r268662: ubuntu@raspberrypi2#> ./corerun ./hello.exe (with -O2/-O3) Hello!!! Welcome to .NET Core (CoreCLR) world.!!! -- 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 27837] New: Improve std::async QoI when implementing new Parallel algorithms
https://llvm.org/bugs/show_bug.cgi?id=27837 Bug ID: 27837 Summary: Improve std::async QoI when implementing new Parallel algorithms Product: libc++ Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified The current implementation of async boots up a new thread for every call. There are likely better implementations, which will become easier to adopt once we have better parallelism machinery. We should look into improving std::async as part of implementing parallel algorithms. -- 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 27838] New: crash at -O2 on x86_64-linxu-gnu in both 32-bit and 64-bit modes (Loops should be in LCSSA form after loop-unroll.)
o -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -resource-dir
/usr/local/clang-trunk/bin/../lib/clang/3.9.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/local/clang-trunk/bin/../lib/clang/3.9.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O2 -w -fdebug-compilation-dir
/data2/c-hunter-results/C/instrument-bugs/REDUCED/20160522-clang-trunk-m64-g-O3-build-171343/delta
-ferror-limit 19 -fmessage-length 220 -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-o /tmp/small-aba209.o -x c small.c
1. parser at end of file
2. Per-module optimization passes
3. Running pass 'CallGraph Pass Manager' on module 'small.c'.
4. Running pass 'Loop Pass Manager' on function '@fn1'
5. Running pass 'Unroll loops' on basic block '%for.cond5.preheader'
clang-3.9: error: unable to execute command: Aborted (core dumped)
clang-3.9: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.9.0 (trunk 270354)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
clang-3.9: 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-3.9: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.9: note: diagnostic msg: /tmp/small-2588f1.c
clang-3.9: note: diagnostic msg: /tmp/small-2588f1.sh
clang-3.9: note: diagnostic msg:
$:
$: cat small.c
int *a;
char b = 3;
void fn1() {
char c;
for (; c - 2; c = c - 6) {
b--;
c = 6;
for (; c >= 0; c--)
for (; a; *a = 1)
;
if (a)
break;
}
}
int main() {}
$:
--
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 27828] Firstprivate in for directive does not work properly.
https://llvm.org/bugs/show_bug.cgi?id=27828 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Alexey Bataev --- The reproducer is not correct - it uses '#pragma for' instead of '#pragma omp for'. After fixing this issue reproducer works correctly, so nothing to fix 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 27839] New: Linear congruential generator generates invalid values
https://llvm.org/bugs/show_bug.cgi?id=27839
Bug ID: 27839
Summary: Linear congruential generator generates invalid values
Product: libc++
Version: 3.7
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: david.g.ham...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
The linear congruential generator generates numbers outside the range of
`min()` and `max()` for some values of `a`, `c`, and `m`. For example,
`std::linear_congruential_engine ` fails badly. These are the values used by `drand48`.
#include
#include
#include
using drand48_engine = std::linear_congruential_engine <
std::uint64_t, 25214903917ull, 11ull, (1ull<<48) >;
int main ()
{
drand48_engine rng;
int pass_fail[2] = {0,0};
for (int ii = 0; ii < 100; ++ii)
{
auto num = rng();
++pass_fail[num < (1ull<<48)];
}
std::cout << "#pass=" << pass_fail[1] << " #fail=" << pass_fail[0] <<
'\n';
}
--
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
