[llvm-bugs] [Bug 26816] [ScalarEvolution] Iteration order over Set depends on pointer values
https://llvm.org/bugs/show_bug.cgi?id=26816 Mattias Eriksson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mattias Eriksson --- I am not able to reproduce the non-determinism on trunk. Closing this issue because it is based on my bad assumption on SetVector. -- 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 26812] possible overflow issue in std::allocator::allocate
https://llvm.org/bugs/show_bug.cgi?id=26812 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marshall Clow (home) --- Fixed in revision 262610. -- 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 19422] polly enabled builds fail ffmpeg fate tests
https://llvm.org/bugs/show_bug.cgi?id=19422 Johannes Doerfert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Johannes Doerfert --- Fixed in r262612. Thanks to Jeremy Huddleston Sequoia for reporting this. Thanks to Roman Gareev for his investigation and the reduced test 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 26828] New: -frewrite-includes: incorrect support of __has_include_next
https://llvm.org/bugs/show_bug.cgi?id=26828
Bug ID: 26828
Summary: -frewrite-includes: incorrect support of
__has_include_next
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: eugvelesev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15980
--> https://llvm.org/bugs/attachment.cgi?id=15980&action=edit
The test mentioned in the bug description.
Now __has_include_next is handled as __has_include:
include_next.cpp:
#include
inc/h.h:
#if __has_include_next() /* expands in 1 */
#include_next
#else
int main() { int inc; }
#endif
inc2/h.h:
#if __has_include_next() /* incorrectly expands in 1 */
#include_next
#else
int main() { int inc2; }
#endif
"clang++ -frewrite-includes -E include_next.cpp -isystem inc -isystem inc2 |
clang++ -E -" produces empty file(with line directives).
--
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 26829] New: Feature specify new lines between namespace declarations
https://llvm.org/bugs/show_bug.cgi?id=26829
Bug ID: 26829
Summary: Feature specify new lines between namespace
declarations
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang-format currently does not modify any of the following three examples,
that is, the user still needs to handle style by hand. It would be nice if this
would be fixed.
Example 1:
namespace A {
namespace B {
namespace C {
} // namespace C
} // namespace B
} // namespace A
Example 2:
namespace A {
namespace B {
namespace C {
} // namespace C
} // namespace B
} // namespace A
Example 3:
namespace A {
namespace B {
namespace C {
} // namespace C
} // namespace B
} // namespace A
For example I would always want no new lines between namespaces and enclosing
brackets like in Example A, but some people might want to follow example 3.
I also sometimes document a new namespace when I introduce it and would like it
to be separately spaced, for example:
namespace A { // already exists
namespace B { // already exists
/// New namespace for C stuff
namespace C {
} // namespace C
} // namespace B
} // namespace A
where I don't introduce any space between A and B, but leave a line in between
when documenting a new namespace and want that to be respected on the enclosing
bracket.
--
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 26830] New: misaligned placement of function arguments of over-aligned type on the stack (ABI incompatibility)
https://llvm.org/bugs/show_bug.cgi?id=26830
Bug ID: 26830
Summary: misaligned placement of function arguments of
over-aligned type on the stack (ABI incompatibility)
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: kr...@kde.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
#include
struct X { __m128 x; };
X f(X a, X b) { return {_mm_add_ps(a.x, b.x)}; }
Compiles to (-msse -m32 -O2):
:
0:· mov0x4(%esp),%eax
4:· movups 0x8(%esp),%xmm0
9:· movups 0x18(%esp),%xmm1
e:· addps %xmm0,%xmm1
11:· movaps %xmm1,(%eax)
14:· ret$0x4
This is incorrect according to the x86 psABI document, which states that
padding must be added so that the placement of the argument matches its
alignment. GCC compiles the code to:
:
0:· movaps 0x24(%esp),%xmm0
5:· mov0x4(%esp),%eax
9:· addps 0x14(%esp),%xmm0
e:· movaps %xmm0,(%eax)
11:· ret$0x4
--
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 23024] -r mode (relocatable link) not implemented
https://llvm.org/bugs/show_bug.cgi?id=23024 ema...@freebsd.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from ema...@freebsd.org --- > D17813 is commited. Not sure if that can be closed then ? Would be nice to > have > confirmation about that functionality is working now in real life. Yes, I'll close it now. The build error I encountered with FreeBSD's libpam/static_modules is solved. I have not run-tested the result but it makes sense for me to submit a new PR for any issues that are found. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 23024, which changed state. Bug 23024 Summary: -r mode (relocatable link) not implemented https://llvm.org/bugs/show_bug.cgi?id=23024 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 26831] New: [ms] macro __FUNCTION__ cannot be used with "comment" and "message" pragmas
https://llvm.org/bugs/show_bug.cgi?id=26831
Bug ID: 26831
Summary: [ms] macro __FUNCTION__ cannot be used with "comment"
and "message" pragmas
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
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 does not recognize macros __FUNCTION__ and __FUNCDNAME__ in #pragma
message and #pragma comment. Ms cl compiler works without errors and prints
function name in this case -!
===ENVIRONMENT==
OS: Windows
Language: c/c++
Version: trunk
===SMALL REPRODUCER=
void func(void) {
#pragma message(__FUNCTION__)
#pragma message("function = " __FUNCTION__)
#pragma message("function = " "WHY_NOT" __FUNCTION__ "\n")
#pragma comment(linker, "/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
#pragma message("/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
}
DIAGNOSTICS==
>>>clang:
test.cpp:2:19: error: expected string literal in pragma message
#pragma message(__FUNCTION__)
test.cpp:3:33: error: pragma message requires parenthesized string
#pragma message("function = " __FUNCTION__)
test.cpp:4:43: error: pragma message requires parenthesized string
#pragma message("function = " "WHY_NOT" __FUNCTION__ "\n")
test.cpp:5:38: error: pragma comment requires parenthesized identifier and
optional string
#pragma comment(linker, "/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
test.cpp:6:30: error: pragma message requires parenthesized string
#pragma message("/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
>>>MSVC/intel icc compiler:
func
function = func
function = WHY_NOTfunc
/EXPORT:func=?func@@YAXXZ
Andrey Kuleshov
==
Software Engineer
Intel Compiler Team
--
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 26734] wrong code at -O2, -O3 (NOT -Os) on x86-64-linux-gnu (in 32- and 64-bit modes)
https://llvm.org/bugs/show_bug.cgi?id=26734 Matthew Simpson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Matthew Simpson --- This should be fixed as of r262624 (test case included with the fix). We should not have tried to vectorize this code because the incoming phi value corresponding to the loop latch block (the previous value) is not defined inside the loop. It's defined in the preheader. This led to the dominance problem Michael discovered. The fix ensures the previous value is defined inside the loop when checking for first-order recurrences. -- 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 26818] lld incorrectly resolves function pointer relocation in dso
https://llvm.org/bugs/show_bug.cgi?id=26818 Rafael Ávila de Espíndola changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Rafael Ávila de Espíndola --- Fixed in r262642. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 26818, which changed state. Bug 26818 Summary: lld incorrectly resolves function pointer relocation in dso https://llvm.org/bugs/show_bug.cgi?id=26818 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26702] [InstCombine] bitcasts hinder simple vector logic ops
https://llvm.org/bugs/show_bug.cgi?id=26702 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Sanjay Patel --- Should be fixed with: http://reviews.llvm.org/rL262645 The original test case reduces to just: vpsrad$31, %xmm0, %xmm0 -- 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 26832] New: __m64 not passed according to x86-64 ABI
https://llvm.org/bugs/show_bug.cgi?id=26832
Bug ID: 26832
Summary: __m64 not passed according to x86-64 ABI
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jykni...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Test program:
#include
__m64 glob;
void (__m64 x) {
glob = x;
}
psABI says "Arguments of types float, double, _Decimal32, _Decimal64 and __m64
are in class SSE." That's pretty clear.
GCC, at least from 4.4.7 through 6 (the versions available at gcc.godbolt.org),
follows the psABI:
movq%xmm0, glob(%rip)
ret
Clang does not:
movq%rdi, glob(%rip)
retq
Clang claims it's doing so for gcc compatibility in a comment:
// gcc passes <1 x double> in memory. :(
// gcc passes <1 x long long> as INTEGER.
but that's not actually true (now; don't know about when the comment was
written)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 20126] clang assertion failure with OpenCL function: "Only storage fields have tail padding!"
https://llvm.org/bugs/show_bug.cgi?id=20126 Matt Arsenault changed: What|Removed |Added Status|NEW |RESOLVED CC||matthew.arsena...@amd.com Resolution|--- |FIXED --- Comment #5 from Matt Arsenault --- I think r189302 fixed 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 26833] New: [CodeView] assertion after optimizing code with debug info
https://llvm.org/bugs/show_bug.cgi?id=26833 Bug ID: 26833 Summary: [CodeView] assertion after optimizing code with debug info Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: r.sagita...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified The attached IR compiles fine with "llc", but triggers an assertion if optimized before with "opt -O2": Assertion failed: cast(Scope)->describes(MF->getFunction()), file C:\s\d\ldc\llvm\lib\CodeGen\LexicalScopes.cpp, line 160 Strangely, it doesn't assert with "llc -O2". The same compiles without debug info. -- 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 26834] New: --sysroot doesn't add the cxx includes
https://llvm.org/bugs/show_bug.cgi?id=26834 Bug ID: 26834 Summary: --sysroot doesn't add the cxx includes Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: vvasi...@cern.ch CC: llvm-bugs@lists.llvm.org Classification: Unclassified Way to reproduce: $ cat T.cpp #include std::basic_string myStr; $ clang -Xclang -header-include-file -Xclang included_files.txt -fsyntax-only T.cpp && sed -i '//d' included_files.txt $cat included_files.txt | xargs -I$ cp --parents $ includes/ Running with GCC seems correct. I.e. it picks the right headers. One way to check this is to introduce an error for instance in ./includes/usr/include/c++/4.9/string GCC Works: gcc-4.9 -fsyntax-only --sysroot="./includes/" T.cpp -v Using built-in specs. COLLECT_GCC=gcc-4.9 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.3-8ubuntu2~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.3 (Ubuntu 4.9.3-8ubuntu2~14.04) COLLECT_GCC_OPTIONS='-fsyntax-only' '-v' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -isysroot ./includes/ -D_GNU_SOURCE T.cpp -quiet -dumpbase T.cpp -mtune=generic -march=x86-64 -auxbase T -version -fsyntax-only -o /dev/null -fstack-protector -Wformat -Wformat-security GNU C++ (Ubuntu 4.9.3-8ubuntu2~14.04) version 4.9.3 (x86_64-linux-gnu) compiled by GNU C version 4.9.3, GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "./includes/usr/include/x86_64-linux-gnu/c++/4.9" ignoring nonexistent directory "./includes/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "./includes/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: ./includes/usr/include/c++/4.9 ./includes/usr/include/x86_64-linux-gnu/c++/4.9 ./includes/usr/include/c++/4.9/backward /usr/lib/gcc/x86_64-linux-gnu/4.9/include /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed ./includes/usr/include/x86_64-linux-gnu ./includes/usr/include End of search list. GNU C++ (Ubuntu 4.9.3-8ubuntu2~14.04) version 4.9.3 (x86_64-linux-gnu) compiled by GNU C version 4.9.3, GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 89e7430b5c7b299a0eb13bf84091b3f2 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:./includes/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:./includes/usr/lib/ COLLECT_GCC_OPTIONS='-fsyntax-only' '-v' '-mtune=generic' '-march=x86-64' Clang does not: clang++ -fsyntax-only --sysroot="./includes/" T.cpp -v clang version 3.8.0 (https://github.com/llvm-mirror/clang.git da6b27875042ee23afaf898f189e410f177311ad) (https://github.com/llvm-mirror/llvm.git 1c23594d2c3887bbb714a55a51770524f7744293) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/vvassilev/workspace/llvm-git/inst/bin Found candidate GCC installation: ./includes//usr/lib/gcc/x86_64-linux-gnu/4.9 "/home/vvassilev/workspace/llvm-git/inst/bin/clang" -cc1 -triple x86_64-un
[llvm-bugs] [Bug 26813] lld-linked FreeBSD libc contains .text relocations
https://llvm.org/bugs/show_bug.cgi?id=26813 ema...@freebsd.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from ema...@freebsd.org --- Marked as duplicate of the version script PR. We have a workaround (PR 26814 or hack to FreeBSD rtld) to continue with the FreeBSD buildworld testing, and there's nothing specific to do for this PR. *** This bug has been marked as a duplicate of bug 23231 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 26813, which changed state. Bug 26813 Summary: lld-linked FreeBSD libc contains .text relocations https://llvm.org/bugs/show_bug.cgi?id=26813 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- 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 26674] --start-lib/--end-lib broken with LTO
https://llvm.org/bugs/show_bug.cgi?id=26674 Evgeniy Stepanov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Evgeniy Stepanov --- Fixed in http://reviews.llvm.org/rL262676 with ToT gold. -- 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 26835] New: clang crashes on valid code at -O1 and above on x86_64-linux-gnu: Assertion `isSimple() && "Expected a SimpleValueType!"' failed
(/usr/local/clang-trunk/bin/clang-3.9+0x2350fe8)
#22 0x0267e73d clang::ParseAST(clang::Sema&, bool, bool)
(/usr/local/clang-trunk/bin/clang-3.9+0x267e73d)
#23 0x023510ae clang::CodeGenAction::ExecuteAction()
(/usr/local/clang-trunk/bin/clang-3.9+0x23510ae)
#24 0x02094e26 clang::FrontendAction::Execute()
(/usr/local/clang-trunk/bin/clang-3.9+0x2094e26)
#25 0x0206db06
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang-3.9+0x206db06)
#26 0x0211db22
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang-3.9+0x211db22)
#27 0x00ab5dc0 cc1_main(llvm::ArrayRef, char const*,
void*) (/usr/local/clang-trunk/bin/clang-3.9+0xab5dc0)
#28 0x00a72efd main (/usr/local/clang-trunk/bin/clang-3.9+0xa72efd)
#29 0x7ff581778ec5 __libc_start_main
/build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:321:0
#30 0x00ab1e44 _start (/usr/local/clang-trunk/bin/clang-3.9+0xab1e44)
Stack dump:
0.Program arguments: /usr/local/clang-trunk/bin/clang-3.9 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb
-coverage-file /home/su/20160303-clang-trunk-m64-O3-build-114341/small.c
-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 -O1 -fdebug-compilation-dir
/home/su/20160303-clang-trunk-m64-O3-build-114341 -ferror-limit 19
-fmessage-length 114 -fobjc-runtime=gcc -fdiagnostics-show-option
-fcolor-diagnostics -o small.o -x c small.c
1. parser at end of file
2.Code generation
3.Running pass 'Function Pass Manager' on module 'small.c'.
4.Running pass 'X86 DAG->DAG Instruction Selection' on function '@fn1'
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 262545)
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-25e85e.c
clang-3.9: note: diagnostic msg: /tmp/small-25e85e.sh
clang-3.9: note: diagnostic msg:
$
--
struct
{
char f0;
unsigned f1:24;
} a;
void
fn1 ()
{
a.f1 %= 3;
}
--
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 26832] __m64 not passed according to x86-64 ABI
https://llvm.org/bugs/show_bug.cgi?id=26832 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Component|-New Bugs |LLVM Codegen Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | --- Comment #1 from David Majnemer --- Fixed in r262688. -- 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
