[llvm-bugs] [Bug 26106] Loop Vectorizer on ARM - why is the relative speedup so much worse?
https://llvm.org/bugs/show_bug.cgi?id=26106 James Molloy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from James Molloy --- Hi, I can't comment on microarchitectural details of ARM CPUs. However the Cortex-A5 is a part that strongly favours efficiency over performance. It would be interesting if you ran this on other ARM parts (for example a Cortex-A15). It is obvious from the numbers that the performance hits a bottleneck/is saturated after vectorization. Unrolling doesn't give much extra gain. This could be due to a number of factors that I'm not keen on speculating on! This is just the theoretical peak performance of that system (because it's not just the CPU, it's the memory bandwidth too) on that benchmark. I'm going to mark this resolved, but feel free to reopen it. James -- 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 26109] New: is_same::value == false
https://llvm.org/bugs/show_bug.cgi?id=26109 Bug ID: 26109 Summary: is_same::value == false Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: dan.el...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified I'm using libc++ from the trusty/universe repo: libc++1_1.0~svn199600-1_amd64.deb is_same is used by unordered_map in a static assert to check that the allocator::value_type is the same as the map value_type. The problem is the map defines value_type as pair. If Key was already a const type (const char *) in this case, somehow it gets double const qualified and is_same fails. If however, I make a typedef of const char* as CString and then define the allocator type as pair the is_same check passes. This seems like a bug to me, double const qualifiers should be ignored by is_same, right? I'm not sure what other compilers do. I hope I reported the bug in the right place, it could well be clang issue. -- 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 25921] 3.7 LLDB is broken on i686, while 3.8 (trunk) is just fine
https://llvm.org/bugs/show_bug.cgi?id=25921 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from lab...@google.com --- I'm gonna close the issue then. It would still be good if you could check out 3.8 early to make sure it works for you. -- 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 26110] New: clang c compiler produces wrong result for the attached c code with -O2 optimzation
https://llvm.org/bugs/show_bug.cgi?id=26110 Bug ID: 26110 Summary: clang c compiler produces wrong result for the attached c code with -O2 optimzation Product: clang Version: 3.7 Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: garunsriniva...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15602 --> https://llvm.org/bugs/attachment.cgi?id=15602&action=edit C file that reproduces the problem A bug in the llvm auto vectoizer produces wrong results for the attached c file. Turning off auto vectorizer produces the right results, but makes the bigger test cases run much slower. Compile the attached c file with xcode 7.0x or later with (clang-700.1.81) (based on LLVM 3.7.0svn) with the following command: bad result: === % clang -O2 bug.c -Wall -o bad % ./bad dbg = 10 10 10 10 10 10 10 10 good result: === % clang -O2 -fno-vectorize bug.c -Wall -o bad %./bad dbg = 15 15 15 15 15 15 15 15 gcc 4.7 % gcc -O2 bug.c -Wall -o bad % ./bad dbg = 15 15 15 15 15 15 15 15 -- 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 24655] The preprocessor returns incorrect ranges of macros with certain combinations of headers
https://llvm.org/bugs/show_bug.cgi?id=24655 Dimitar Dobrev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Dimitar Dobrev --- It turned out to be a bug in our code. -- 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 26111] New: Segmentation fault with __attribute__((mode(QI)))
https://llvm.org/bugs/show_bug.cgi?id=26111
Bug ID: 26111
Summary: Segmentation fault with __attribute__((mode(QI)))
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: andrey.kules...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
!- clang crashes with a segfault during parsing __attribute__((mode(QI)))
applied to a function -!
=ENVIRONMENT===
OS (host/target): Linux
Platform: x86_64
Version: trunk
=HOW TO REPRODUCE===
int foo () __attribute__((mode(QI))){ //this line causes segfault
return 0;
}
int main (){
return 0;
}
ERROR==
test_attr.c:1:27: warning: GCC does not allow 'mode' attribute in this position
on a function definition [-Wgcc-compat]
int foo () __attribute__((mode(QI))){
^
test_attr.c:1:27: error: mode attribute only supported for integer and
floating-point types
#0 0x02c47c38 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
PATH/llvm/lib/Support/Unix/Signals.inc:322:0
#1 0x02c47fb4 PrintStackTraceSignalHandler(void*)
PATH/llvm/lib/Support/Unix/Signals.inc:380:0
#2 0x02c46739 llvm::sys::RunSignalHandlers()
PATH/llvm/lib/Support/Signals.cpp:44:0
#3 0x02c47750 SignalHandler(int)
PATH/llvm/lib/Support/Unix/Signals.inc:210:0
#4 0x7f5a2bbd2130 __restore_rt (/lib64/libpthread.so.0+0xf130)
#5 0x02deab56 clang::FunctionType::getReturnType() const
PATH/llvm/tools/clang/include/clang/AST/Type.h:2977:0
#6 0x02deb8a2 clang::FunctionDecl::getReturnType() const
PATH/llvm/tools/clang/include/clang/AST/Decl.h:1958:0
#7 0x04227f90 clang::Sema::CheckFunctionDeclaration(clang::Scope*,
clang::FunctionDecl*, clang::LookupResult&, bool)
PATH/llvm/tools/clang/lib/Sema/SemaDecl.cpp:8326:0
#8 0x042264cf clang::Sema::ActOnFunctionDeclarator(clang::Scope*,
clang::Declarator&, clang::DeclContext*, clang::TypeSourceInfo*,
clang::LookupResult&, llvm::MutableArrayRef,
bool&) PATH/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7917:0
#9 0x0421ae90 clang::Sema::HandleDeclarator(clang::Scope*,
clang::Declarator&, llvm::MutableArrayRef)
PATH/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4989:0
#10 0x04232621 clang::Sema::ActOnStartOfFunctionDef(clang::Scope*,
clang::Declarator&, llvm::MutableArrayRef,
clang::Sema::SkipBodyInfo*) PATH/llvm/tools/clang/lib/Sema/SemaDecl.cpp:10685:0
#11 0x03e5d3a6
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)
PATH/llvm/tools/clang/lib/Parse/Parser.cpp:1076:0
#12 0x03e77be3 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*)
PATH/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1755:0
#13 0x03e5ca88
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
PATH/llvm/tools/clang/lib/Parse/Parser.cpp:928:0
#14 0x03e5cb40
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
PATH/llvm/tools/clang/lib/Parse/Parser.cpp:943:0
#15 0x03e5c2a8
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) PATH/llvm/tools/clang/lib/Parse/Parser.cpp:801:0
#16 0x03e5b72f
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&)
PATH/llvm/tools/clang/lib/Parse/Parser.cpp:593:0
#17 0x03e57c7f clang::ParseAST(clang::Sema&, bool, bool)
PATH/llvm/tools/clang/lib/Parse/ParseAST.cpp:151:0
#18 0x032aef80 clang::ASTFrontendAction::ExecuteAction()
PATH/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:540:0
#19 0x03640033 clang::CodeGenAction::ExecuteAction()
PATH/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:792:0
#20 0x032aea27 clang::FrontendAction::Execute()
PATH/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:443:0
#21 0x03266796
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
PATH/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:841:0
#22 0x033a11c6
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
PATH/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:222:0
#23 0x014c87ee cc1_main(llvm::ArrayRef, char const*,
void*) PATH/llvm/tools/clang/tools/driver/cc1_main.cpp:116:0
#24 0x014bf0b1 ExecuteCC1Tool(llvm::ArrayRef,
llvm::StringRef) PATH/llvm/tools/clang/tools/driver/driver.cpp:301:0
#25 0x014bfa31 main PATH/llvm/tools/clang/tools/driver/driver.cpp:366:0
#26 0x7f5a2adf3af5 __libc_start_main (/lib64/libc.so.6+0x21af5)
#27 0x014
[llvm-bugs] [Bug 26112] New: [REGRESSION] Compiler aborts in LTO while building SPEC benchmarks
https://llvm.org/bugs/show_bug.cgi?id=26112 Bug ID: 26112 Summary: [REGRESSION] Compiler aborts in LTO while building SPEC benchmarks Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: santosh.zanju...@amd.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15603 --> https://llvm.org/bugs/attachment.cgi?id=15603&action=edit Test case The regression is introduced in svn r257164. Test case, log and command attached. SPEC cpu 2006 bechmark failed with below assert: clang-3.8: error: unable to execute command: Segmentation fault (core dumped) clang-3.8: error: linker command failed due to signal (use -v to see invocation) -- 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 26109] is_same::value == false
https://llvm.org/bugs/show_bug.cgi?id=26109 Dan Eloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dan Eloff --- Sorry, you're completely right. That's exactly what I'm seeing, and all I needed to do was declare the allocator using pair to get it to compile. So the bug is between the chair and the keyboard! Thanks, Dan -- 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 26113] New: python-lldb-3.8 does not contain lldb python module
https://llvm.org/bugs/show_bug.cgi?id=26113 Bug ID: 26113 Summary: python-lldb-3.8 does not contain lldb python module Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: tomasz.mia...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I'm trying to use lldb-3.8 together with python, but lldb has trouble importing lldb module: Traceback (most recent call last): File "", line 1, in ImportError: No module named lldb.embedded_interpreter I am not sure what is main underlying cause, but I noticed a few potential issues. 1. Neither lldb-3.8, nor liblldb-3.8, nor python-lldb-3.8 seem to contain Python module named lldb. Probably the closes one is liblldb-3.8 which contains binary module named _lldb.so. 2. python-lldb-3.8 doesn't have any dependencies besides Python (maybe there is yet another package that is required to make this work?) 3. python-lldb-3.8, contains invalid symbolic links, in particular two of following: ./usr/lib/llvm-3.8/lib/python2.7/site-packages/lldb/libLLVM-3.8.0.so.1 -> ../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1 ./usr/lib/llvm-3.8/lib/python2.7/site-packages/lldb/libLLVM-3.8.so.1 -> ../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1 After canonicalization, they point to following non-existing file: /usr/lib/llvm-3.8/lib/x86_64-linux-gnu/libLLVM-3.8.0.so.1 On the other hand, I have libLLVM-3.8.0 in following locations (first one is symbolic link to the second one): /usr/lib/llvm-3.8/lib/libLLVM-3.8.0.so.1 /usr/lib/x86_64-linux-gnu/libLLVM-3.8.so.1 I use following apt repository: deb http://llvm.org/apt/vivid/ llvm-toolchain-vivid main Thanks, Tomasz -- 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 26114] New: Many unnecessary mov instructions near call site
https://llvm.org/bugs/show_bug.cgi?id=26114
Bug ID: 26114
Summary: Many unnecessary mov instructions near call site
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: atr...@apple.com, hfin...@anl.gov,
llvm-bugs@lists.llvm.org, qcolom...@apple.com
Classification: Unclassified
Test case:
void foo(char *c, short s, float X, char C, long long LL, int I, double D);
void test(short s, float X, char C, long long LL, int I, double D) {
foo("test", s, X, C, LL, I, D);
}
On AArch64 at -O3 the assembly output is as follows:
test:
mov w8, w3
mov x9, x2
mov w10, w1
mov w11, w0
adrpx0, .L.str
add x0, x0, :lo12:.L.str
mov w1, w11
mov w2, w10
mov x3, x9
mov w4, w8
b foo
We should be able to generate something like this:
test:
adrpx5, .LC0
mov w4, w3
mov x3, x2
mov w2, w1
mov w1, w0
add x0, x5, :lo12:.LC0
b foo
Which has 4 fewer moves.
--
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 16677] Crash on invalid: using a comma instead of closing angle bracket for template.
https://llvm.org/bugs/show_bug.cgi?id=16677 Serge Pavlov changed: What|Removed |Added Status|NEW |RESOLVED CC||sepavl...@gmail.com Resolution|--- |FIXED --- Comment #2 from Serge Pavlov --- The problem was fixed in r256511. -- 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 26115] New: [Inliner] Callee with single call instruction not being inlined
https://llvm.org/bugs/show_bug.cgi?id=26115
Bug ID: 26115
Summary: [Inliner] Callee with single call instruction not
being inlined
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Test case ([test-suite] SingleSource/UnitTests/2003-10-29-ScalarReplBug.c):
#include
typedef struct {
char name [80];
int val;
unsigned uval;
} data;
static int callback(void *d);
static void iter(int (*)(void*), void *);
static int callback(void *d)
{
data *iter_data = (data *)d;
printf("%u\n", iter_data->uval);
return iter_data->uval == 0;
}
static void iter(int (*cb)(void*), void *d)
{
cb(d);
}
int main()
{
data d;
d.uval = 0;
iter(callback, &d);
return 0;
}
On AArch64 we currently generate the following assembly:
--
.text
.file"2003-10-29-ScalarReplBug.c"
.globlmain
.align2
.typemain,@function
main: // @main
// BB#0:// %entry
stpx29, x30, [sp, #-16]!
mov x29, sp
subsp, sp, #96 // =96
addx0, sp, #8 // =8
strwzr, [sp, #92]
bliter
mov w0, wzr
mov sp, x29
ldpx29, x30, [sp], #16
ret
.Lfunc_end0:
.sizemain, .Lfunc_end0-main
.align2
.typeiter,@function
iter: // @iter
// BB#0:// %entry
bcallback
.Lfunc_end1:
.sizeiter, .Lfunc_end1-iter
.align2
.typecallback,@function
callback: // @callback
// BB#0:// %entry
stpx20, x19, [sp, #-32]!
stpx29, x30, [sp, #16]
mov x19, x0
ldrw1, [x19, #84]
adrpx0, .L.str
addx0, x0, :lo12:.L.str
addx29, sp, #16// =16
blprintf
ldrw8, [x19, #84]
ldpx29, x30, [sp, #16]
cmpw8, #0 // =0
cset w0, eq
ldpx20, x19, [sp], #32
ret
.Lfunc_end2:
.sizecallback, .Lfunc_end2-callback
.type.L.str,@object // @.str
.section.rodata.str1.1,"aMS",@progbits,1
.L.str:
.asciz"%u\n"
.size.L.str, 4
.ident"clang version 3.8.0 (trunk 257341) (llvm/trunk 257344)"
.section".note.GNU-stack","",@progbits
--
Considering the body of iter is a single call to 'callback' I imagine it would
make sense to inline the call to iter.
--
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 26116] New: RuntimeDyldCOFFI386 error on IMAGE_REL_I386_REL32 for global function address mapping
https://llvm.org/bugs/show_bug.cgi?id=26116
Bug ID: 26116
Summary: RuntimeDyldCOFFI386 error on IMAGE_REL_I386_REL32 for
global function address mapping
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: Generic Execution Engine Support
Assignee: unassignedb...@nondot.org
Reporter: vivien.mil...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In RuntimeDyldCOFFI386.h
After Line: 151
We have :
uint64_t Result = Sections[RE.Sections.SectionA].getLoadAddress() -
Section.getLoadAddress() + RE.Addend - 4 - RE.Offset;
BUT
In case of global native C++ function mapping
(ExecutionEngine::addGlobalMapping(...)), RE.Sections.SectionA equals -1
(0x) which triggers a bad index assertion.
Analysing and comparing to the In RuntimeDyldCOFFX86_64, we should treat a
special case when SectionA == -1
I propose that code which works fine for me and retrieves on code generation
the good global address (i put the whole switch case)
case COFF::IMAGE_REL_I386_REL32: {
// 32-bit relative displacement to the target.
uint64_t Result;
if(RE.Sections.SectionA == static_cast(-1))
{
uint64_t FinalAddress = Section.getLoadAddressWithOffset(RE.Offset);
Value -= FinalAddress + 4;
Result = Value + RE.Addend;
}
else
{
Result = Sections[RE.Sections.SectionA].getLoadAddress() -
Section.getLoadAddress() + RE.Addend - 4 - RE.Offset;
}
assert(static_cast(Result) <= INT32_MAX &&
"relocation overflow");
assert(static_cast(Result) >= INT32_MIN &&
"relocation underflow");
DEBUG(dbgs() << "\t\tOffset: " << RE.Offset
<< " RelType: IMAGE_REL_I386_REL32"
<< " TargetSection: " << RE.Sections.SectionA
<< " Value: " << format("0x%08" PRIx32, Result) << '\n');
writeBytesUnaligned(Result, Target, 4);
break;
--
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 23602] clang++ fails to compile libstdc++ debug/vector with -D_GLIBCXX_DEBUG -std=c++11 with libstdc++ 5.1+
https://llvm.org/bugs/show_bug.cgi?id=23602 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Nico Weber --- *** This bug has been marked as a duplicate of bug 23381 *** -- 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 26117] New: msvc-cl and clang-cl disagree on what can be static_asserted
https://llvm.org/bugs/show_bug.cgi?id=26117
Bug ID: 26117
Summary: msvc-cl and clang-cl disagree on what can be
static_asserted
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: jmuizel...@mozilla.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following program compiles with msvc-cl but does not with clang-cl.
The Offsetof macro is the one from msvc's stddef.h
#include
#define Offsetof(s,m) (size_t)( (ptrdiff_t)&reinterpret_casts *)0)->m)) )
struct MyClass {
int myMem;
};
static_assert(Offsetof(MyClass, myMem) == 0, "boom");
You can run into this when pre-processing source from msvc to compile with
clang-cl.
--
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 26110] clang c compiler produces wrong result for the attached c code with -O2 optimzation
https://llvm.org/bugs/show_bug.cgi?id=26110 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- The bug doesn't reproduce for me on trunk (r257365), so I'm going to resolve it as 'fixed'. I tried to use llvm bisect to find where this changed: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091140.html $ llvmlab bisect /bin/sh -c '%(path)s/bin/clang -O2 bug.c && ./a.out | grep "10"' clang-r229097-t2015-02-13_02-38-20-b4745: first working build clang-r229100-t2015-02-13_02-58-18-b4746: next failing build That seems too far back, so I'm not sure if I invoked that correctly. -- 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 26117] msvc-cl and clang-cl disagree on what can be static_asserted
https://llvm.org/bugs/show_bug.cgi?id=26117 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Smith --- Neither GCC nor MSVC properly implement the C++11 constant expression rules in this area. Casting between pointers and integers is not permitted in a constant expression (and nor is the reinterpret_cast to cv char&). Reid, it sounds like you don't think this is worth supporting as an MSVC compatibility hack, so I'm going to close this. Please reopen if this is important for MSVC compatibility on some important headers. -- 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 25999] spec2000/188.ammp, spec2006/433.milc, 444.namd, 447.dealII, 453.povray compilation fails on LTO stage after commit r256394
https://llvm.org/bugs/show_bug.cgi?id=25999 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Sanjay Patel --- Thanks all for the test cases; sorry for the breakage. Resolving 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 26087] Building clangDynamicASTMatchers fails on Visual Studio 2015 in REGISTER_MATCHER(hasDeclaration);
https://llvm.org/bugs/show_bug.cgi?id=26087 James Y Knight changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |jykni...@google.com |org | --- Comment #4 from James Y Knight --- Fixed with r257392: PR26087: Use nonstandard MSVC extension for VS2015 as well. In r256564, I had conditioned the workaround in has_getDecl to only be used for MSVC before the 2015 release, believing that 2015 could handle the standard code. But, that was incorrect. -- 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 26088] Some AST matcher tests fail to compile on Visual Studio 2015.
https://llvm.org/bugs/show_bug.cgi?id=26088 juj...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from juj...@gmail.com --- Looks like this was caused by https://llvm.org/bugs/show_bug.cgi?id=26087, and was resolved after that was 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 26095] -fsanitize=object-size checks sizes too eagerly
https://llvm.org/bugs/show_bug.cgi?id=26095 George Burgess changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from George Burgess --- After consulting someone with far more knowledge of C++ than I, it seems that the example program does have UB; casting from base->derived using static_cast is UB if the pointee isn't an instance of derived. Oops. :) Closing this. -- 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 25802] Assertion `Hi->getOffset() >= Lo->getOffset() && "Expected Hi to be greater than Lo"' failed
https://llvm.org/bugs/show_bug.cgi?id=25802 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Rafael Ávila de Espíndola --- Fixed in r257412. -- 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 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 25802, which changed state. Bug 25802 Summary: Assertion `Hi->getOffset() >= Lo->getOffset() && "Expected Hi to be greater than Lo"' failed https://llvm.org/bugs/show_bug.cgi?id=25802 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 25780] [META] Using Clang as the FreeBSD/ppc system compiler
https://llvm.org/bugs/show_bug.cgi?id=25780 Bug 25780 depends on bug 25802, which changed state. Bug 25802 Summary: Assertion `Hi->getOffset() >= Lo->getOffset() && "Expected Hi to be greater than Lo"' failed https://llvm.org/bugs/show_bug.cgi?id=25802 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 26118] New: TBAA failed to alias union in a very obvious code
https://llvm.org/bugs/show_bug.cgi?id=26118
Bug ID: 26118
Summary: TBAA failed to alias union in a very obvious code
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: yi...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
###---t.c###
typedef union
{
unsigned int b32[2];
long long int b64;
} Vector;
int bar();
unsigned int h264p_get_bits(Vector *c)
{
unsigned int v = c->b64;
c->b32[0]= bar();
return v;
}
clang t.c -S -O1 -mllvm -print-after-all
*** IR Dump After Module Verifier ***
; Function Attrs: nounwind
define i32 @h264p_get_bits(%union.Vector* %c) #0 {
entry:
%c.addr = alloca %union.Vector*, align 4
%v = alloca i32, align 4
store %union.Vector* %c, %union.Vector** %c.addr, align 4, !tbaa !3
%0 = bitcast i32* %v to i8*
call void @llvm.lifetime.start(i64 4, i8* %0) #3
%1 = load %union.Vector*, %union.Vector** %c.addr, align 4, !tbaa !3
%b64 = bitcast %union.Vector* %1 to i64*
%2 = load i64, i64* %b64, align 8, !tbaa !7 <<<- !7
%conv = trunc i64 %2 to i32
store i32 %conv, i32* %v, align 4, !tbaa !9
%call = call i32 bitcast (i32 (...)* @bar to i32 ()*)()
%3 = load %union.Vector*, %union.Vector** %c.addr, align 4, !tbaa !3
%b32 = bitcast %union.Vector* %3 to [2 x i32]*
%arrayidx = getelementptr inbounds [2 x i32], [2 x i32]* %b32, i32 0, i32 0
store i32 %call, i32* %arrayidx, align 8, !tbaa !9 <<<- !9, not !7
%4 = load i32, i32* %v, align 4, !tbaa !9
%5 = bitcast i32* %v to i8*
call void @llvm.lifetime.end(i64 4, i8* %5) #3
ret i32 %4
}
Although I understand
Strictly speaking, reading a member of a union different from the one written
to is undefined in ANSI/ISO C99 except in the special case of type-punning to a
char*, similar to the example below: Casting to char*. However, it is an
extremely common idiom and is well-supported by all major compilers. As a
practical matter, reading and writing to any member of a union, in any order,
is acceptable practice.
And for type based AA, it should not strict aligned. However, for union, this
is very general usage, tbaa should output they are aliased, right.
--
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 25939] Regression(256332:256344): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed while building chrome
https://llvm.org/bugs/show_bug.cgi?id=25939 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nico Weber --- Thanks! Our bots stayed green this time. -- 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
