[llvm-bugs] [Bug 26447] New: Possible (probable?) bug in computing LiveRange overlap
https://llvm.org/bugs/show_bug.cgi?id=26447 Bug ID: 26447 Summary: Possible (probable?) bug in computing LiveRange overlap Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: stephen.montgomery...@gmail.com CC: llvm-bugs@lists.llvm.org, qcolom...@apple.com Classification: Unclassified Created attachment 15807 --> https://llvm.org/bugs/attachment.cgi?id=15807&action=edit Possible fix for LiveRange::overlaps bug with CoalescerPair I submitted this recently to the llvmdev mailing list but didn't get any feedback so I'm taking the plunge and reporting it as a bug. My backend for the Freescale S12X micro controller family failed with a "ran out of registers during register allocation" message recently. I traced the issue down to the code that checks whether two LiveRanges have overlapping segments that are not coalescable. I’ve got two ranges [608r,656r:0)[656r,672r:1) and [0B,32r)[672r,688r). I don’t believe that these overlap though maybe I've misunderstood how LiveRanges work. In any event, if I iterate over one LiveRange's segments and use LiveRange::overlaps(SlotIndex Start, SlotIndex End) I don't get any overlap. However, the version of LiveRange::overlaps that takes a CoalescerPair and checks for coalescable segments thinks that these ranges _do_ overlap. I think the problem is in the loop that advances the iterator that ends earliest. I think it should advance until J->end > I->start, not >=. That way, I think it would have the same effect as LiveRange::find() which is what I believe the code is aiming to do, just more efficiently than find(). I've checked against the trunk (my work is based off version 3.7) and there haven't been any changes in this area so I believe the bug is still present. I’ve attached a patch which seems to fix things for me. I don't see any regressions for the supported backends when using 'check-all' having applied this fix. It may be I'm just hitting the bug because the S12X has very few registers and many restrictions on which registers can be used in certain instructions. -- 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 26288] Clang FE fails with assertion "DelayedTypos.empty() && "Uncorrected typos!"
https://llvm.org/bugs/show_bug.cgi?id=26288 Denis Zobnin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Denis Zobnin --- Fixed in r259532. === Denis Zobnin Intel Compiler Engineer Intel -- 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 26448] New: Ternary operator: Incorrect value category
https://llvm.org/bugs/show_bug.cgi?id=26448
Bug ID: 26448
Summary: Ternary operator: Incorrect value category
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: roman.perepeli...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following program unexpectedly triggers the static assertion.
#include
template
using common = decltype(true ? std::declval() : std::declval());
struct base {};
struct derived : base {};
// common is expected to be base&& (see [expr.cond]/3.2),
// but clang produces base. Hence the assertion fails.
static_assert(std::is_same, base&&>(), "");
GCC works correctly on this code snippet.
Note that the following assertion holds (expected behaviour):
static_assert(std::is_same, base&&>(), "");
Confirmed for clang up to 3.7.1 via gcc.godbolt.org (http://goo.gl/srkhK5).
--
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 26449] New: Bugs in __builtin_classify_type implementation
https://llvm.org/bugs/show_bug.cgi?id=26449
Bug ID: 26449
Summary: Bugs in __builtin_classify_type implementation
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: andreybokha...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
There are several bugs in __builtin_classify_type implementation:
1) It doesn't support member functions, so the following program crashes clang:
lass cl {
public:
void bar() {}
};
...
int res = __builtin_classify_type(&cl::bar);
2) It returns enumeral_type_class for enums, function_type_class for functions
and array_type_class for arrays in both C and C++ modes. However, gcc returns
integer_type_class for enums and pointer_type_class for arrays and functions in
C mode -- which is correct, as conversions between enums and ints and function
pointers and arrays and pointers can happen everywhere in C. (gcc returns the
same as what clang does in C++ mode, however.)
2) It returns string_type_class for chars, which is odd and doesn't match what
gcc does.
Yours,
Andrey
==
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 26450] New: ARM code runs 2x slower compared to gcc
https://llvm.org/bugs/show_bug.cgi?id=26450 Bug ID: 26450 Summary: ARM code runs 2x slower compared to gcc Product: clang Version: 3.7 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: tulip...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15810 --> https://llvm.org/bugs/attachment.cgi?id=15810&action=edit C source sample I've recently discovered the sad fact code produced by LLVM on ARM was nowhere near the speed of gcc: https://users.rust-lang.org/t/executable-size-and-performance-vs-c/ The same C code (as well as rust code) compiled with -O3 yields identical performance on x86_64 between gcc/clang/rustc whereas on armv7: gcc - 1.5s clang/rustc - 3.4s (3.2s using --ffast-math) -- 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 24706] clang generate wrong WORD mode for x32
https://llvm.org/bugs/show_bug.cgi?id=24706 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- Fixed by r259383. -- 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 22760] TestCases/stale_stack_leak.cc fails on Fedora 21
https://llvm.org/bugs/show_bug.cgi?id=22760 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from H.J. Lu --- Passed as of r259493. -- 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 26451] New: Spurious use after free warning when using %p
https://llvm.org/bugs/show_bug.cgi?id=26451
Bug ID: 26451
Summary: Spurious use after free warning when using %p
Product: clang
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: sits...@yahoo.com
CC: llvm-bugs@lists.llvm.org
Depends on: 26221
Classification: Unclassified
Created attachment 15814
--> https://llvm.org/bugs/attachment.cgi?id=15814&action=edit
C program that demonstrates spurious use after free warning
Description of the problem:
Code that prints the address of a pointer after the memory has been freed
triggers a "Use of memory after it is freed" warning even though the pointer
itself is not dereferenced.
Steps to reproduce:
1. Compile the attached C program using
scan-build cc -O1 spurious-printf-use-after-free.c -c
Expected results:
No warnings.
Actual results:
# scan-build: Using '/usr/bin/clang' for static analysis
spurious-printf-use-after-free.c:11:2: warning: Use of memory after it is freed
printf("%p\n", (void *)p);
^
1 warning generated.
Additional information:
This problem was identified by Barry Davis of StorMagic.
Version information:
llvm-3.7.0-3.fc23.x86_64
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
--
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 26452] New: LLVM emits divide by zero where there was none
https://llvm.org/bugs/show_bug.cgi?id=26452 Bug ID: 26452 Summary: LLVM emits divide by zero where there was none Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: j...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This test: https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite/gcc.c-torture/execute/pr60960.c Uses 4x vectors and scalarizes the operations. It doesn't divide by zero, yet LLVM generates the following for f1: f1: # @f1 .param i32, i32, i32, i32, i32 # BB#0: # %entry i32.const $push0=, 255 i32.and $push3=, $2, $pop0 i32.const $push8=, 0 i32.div_u $2=, $pop3, $pop8 i32.const $push19=, 255 i32.and $push2=, $3, $pop19 i32.const $push18=, 0 i32.div_u $3=, $pop2, $pop18 i32.const $push10=, 3 i32.add $push11=, $0, $pop10 i32.const $push17=, 255 i32.and $push1=, $4, $pop17 i32.const $push16=, 0 i32.div_u $push9=, $pop1, $pop16 i32.store8 $discard=, 0($pop11):p2align=2, $pop9 i32.const $push12=, 2 i32.add $push13=, $0, $pop12 i32.store8 $discard=, 0($pop13):p2align=2, $3 i32.const $push6=, 1 i32.add $push14=, $0, $pop6 i32.store8 $discard=, 0($pop14):p2align=2, $2 i32.const $push4=, 254 i32.and $push5=, $1, $pop4 i32.const $push15=, 1 i32.shr_u $push7=, $pop5, $pop15 i32.store8 $discard=, 0($0):p2align=2, $pop7 return .endfunc .Lfunc_end0: .size f1, .Lfunc_end0-f1 -- 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 26450] ARM code runs 2x slower compared to gcc
https://llvm.org/bugs/show_bug.cgi?id=26450 James Molloy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from James Molloy --- Hi, OK, there's two things here: Firstly, it seems __umodsi3 and friends are significantly slower than __aeabi_idivmod. GCC is generating __aeabi_idivmod - perhaps we should? We select __modsi3 unless the target is EABI or Android - I suspect that should be EABI, Android or GNUEABI. GCC 4.9:1.24s Clang 3.7: 3.48s Clang 3.7 (using __aeabi_idivmod): 1.15s Secondly, you're not specifying a CPU. That's why your division is going out to the library. Unless you're on a Cortex-A9, you'll have hardware division. Use -mcpu to enable it. GCC 4.9 with -mcpu=cortex-a15: 276ms Clang 3.7 with -mcpu=cortex-a15: 258ms (I had to switch to using perf stat's task-clock metric because time elapsed was getting too noisy) By the way: "I've just discovered how immature LLVM/Clang was on ARM." (from https://users.rust-lang.org/t/executable-size-and-performance-vs-c/4496/34) That's a little over the top - the ARM backend is around 10 years old now, it's fairly mature. 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 26450] ARM code runs 2x slower compared to gcc
https://llvm.org/bugs/show_bug.cgi?id=26450 James Molloy changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #6 from James Molloy --- Woops, I didn't mean to resolve it. We should look at whether we use __aeabi_* or __mod* for Linux targets without hardware divide. -- 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 26071, which changed state. Bug 26071 Summary: wrong code at -Os and above on x86_64-linux-gnu (DemandedBits) https://llvm.org/bugs/show_bug.cgi?id=26071 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 26071] wrong code at -Os and above on x86_64-linux-gnu (DemandedBits)
https://llvm.org/bugs/show_bug.cgi?id=26071 James Molloy changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from James Molloy --- Reverted in r259649. I had to remove a LoopVectorize test that is now failing, so I will need to go think about how to implement this in a sane way. -- 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 26453] New: Regression(259616:259623): Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr while building chromium
https://llvm.org/bugs/show_bug.cgi?id=26453 Bug ID: 26453 Summary: Regression(259616:259623): Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr while building chromium Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified On most platforms (android, mac, 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 26389] [x86-64] clang generate wrong instruction for cygwin
https://llvm.org/bugs/show_bug.cgi?id=26389 swigger changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from swigger --- (In reply to comment #1) > Windows doesn't support executables or DLLs larger than 2GB, so cout must be > coming from another DLL. > > In that case, data imported from another DLL must be annotated as dllimport. > This is not required for functions as import libraries generally provide > thunks to make sure things work out. NO! The source code shipped with cygwin does not write a dllimport with cout. Proof: $ cat a.cpp #include $ gcc -E a.cpp | grep cout extern ostream cout; extern wostream wcout; $ uname -a CYGWIN_NT-6.1 home-PC 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin Neither cygwin nor msys2 likes dllimport since this will cause many problems for building gnu world sources. A more posix likes way would be the best, but needs help from the compiler. I am talking the target x86_64-pc-cygwin not x64_64-pc-windows. Assume extern data is in 2G range is not a bug on windows natively, but it *IS* a *BUG* on cygwin/msys2. -- 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 26454] New: [3.8.0] omp parallel for simd unexpected behaviour at different optimization levels
https://llvm.org/bugs/show_bug.cgi?id=26454 Bug ID: 26454 Summary: [3.8.0] omp parallel for simd unexpected behaviour at different optimization levels Product: OpenMP Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: bugzi...@hannes.hauswedell.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15815 --> https://llvm.org/bugs/attachment.cgi?id=15815&action=edit small benchmark I have created a little example to compare the vectorization support of clang vs gcc and the possible benefits of combining omp parallel and simd. These are the results, g++ is 5.3.0 and clang++ is 3.7.1 / 3.8.d20150720_1 (I know, not the most recent snapshot); I have limited OMP_NUM_THREADS to 2, so that we still get a clear picture. g++5 test.cpp -std=c++14 -fopenmp -O0 auto: 4.07434 omp parallel for: 2.03428 omp simd: 3.24567 omp parallel for simd: 1.85369 g++5 test.cpp -std=c++14 -fopenmp -O3 auto: 0.595322 omp parallel for: 0.410147 omp simd: 0.514423 omp parallel for simd: 0.383947 clang++37 test.cpp -std=c++14 -fopenmp -O0 auto: 2.91202 omp parallel for: 2.44816 omp simd: 2.95256 omp parallel for simd: 1.82498 clang++37 test.cpp -std=c++14 -fopenmp -O3 auto: 0.619024 omp parallel for: 0.412554 omp simd: 0.593244 omp parallel for simd: 0.403466 clang++-devel test.cpp -std=c++14 -fopenmp -O0 auto: 2.91251 omp parallel for: 1.72933 omp simd: 2.95548 omp parallel for simd: 2.14271 clang++-devel test.cpp -std=c++14 -fopenmp -O3 auto: 0.616876 omp parallel for: 0.289257 omp simd: 0.557144 omp parallel for simd: 0.289215 The first observation: clang38 is faster or the same speed as GCC in auto, omp parallel for and omp simd, both with and without optimization. With optimization there is also a significant speed-up of clang38 over clang37 and gcc! Congratulations :) For "#pragma omp parallel for simd" it is different. I know this is an OPENMP4 feature and for -03 clang37 and 38 correctly warn me: warning: loop not vectorized: failed explicitly specified loop vectorization [-Wpass-failed] Hence the speed of "parallel for" and "parallel for simd" are the same on clang37 and clang38. However for -00 there is no warning which I would consider a bug, BUT the runtime is also different. It is better than simd and worse than parallel which means it is doing neither and something else instead, could be another bug... but what is actually happening there? Thank you for taking the time and providing this excellent compiler! PS: Is there an ETA for #pragma omp parallel for simd ? -- 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 26450] ARM code runs 2x slower compared to gcc
https://llvm.org/bugs/show_bug.cgi?id=26450 Renato Golin changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Renato Golin --- Fixed on r259657. It turns out it wasn't a regression, but a long term FIXME. I remember this decision was taken because isTargetEABI didn't cover GNU and we didn't have isTargetGNUEABI at the time, so I assumed the worse, given the problems we had with __aeabi_mem*. Not only we have a check for gnueabi now, but it's also always safe (and many times profitable) to call __aeabi_divmod*, which doesn't have the same problem as the memory builtins. I'm not sure we'll get it into 3.8.0, but I'm marking it for 3.8.1 for sure, which will come in the next few months. -- 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 26455] New: no warning about implicit integer to pointer conversions on x86_64
https://llvm.org/bugs/show_bug.cgi?id=26455 Bug ID: 26455 Summary: no warning about implicit integer to pointer conversions on x86_64 Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: knut.loren...@degree53.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I noticed the [CLANG_WARN_INT_CONVERSION, -Wint-conversion] produces a warning when implicitly converting a pointer into an integer for the ARM architectures, but not for x86. steps to reproduce: - in Xcode, create a project for iOS - add an ObjC method that has a BOOL as return type, but returns a pointer in the implementation - build for armv7/arm64 (generic iOS device) - will produce a warning - build for x86_64 (iOS simulator) - no warning! Apple LLVM version 7.0.2 (clang-700.1.81) Xcode 7.2.1 OS X 10.11 El Capitan -- 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 26456] New: clang assert !R.empty() && "empty lookup results when building templateid"
https://llvm.org/bugs/show_bug.cgi?id=26456
Bug ID: 26456
Summary: clang assert !R.empty() && "empty lookup results when
building templateid"
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: yaron.ke...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
clang -fsyntax-only on :
class FESystem {
templatehp_object_dof_identities (} FESystem:a(
hp_object_dof_identities<>(
results in expected compilation errors Assertion failed: !R.empty() && "empty
lookup results when building templateid", file
C:\llvm\tools\clang\lib\Sema\SemaTemplate.cpp, line 2907
clang version 3.9.0 (trunk 259648)
Target: x86_64-pc-windows-msvc
--
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 26457] New: In std=g++11, conversion using P::operator const std::string fails
https://llvm.org/bugs/show_bug.cgi?id=26457 Bug ID: 26457 Summary: In std=g++11, conversion using P::operator const std::string fails Product: clang Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: quicklydelive...@sogetthis.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15816 --> https://llvm.org/bugs/attachment.cgi?id=15816&action=edit testcase Appended testcase fails to compile on clang 3.7 in C++11. G++ fails not, which does not have to mean anything. Who's right and who's wrong? $ clang -v clang version 3.7.0 (tags/RELEASE_370/final 246586) Target: x86_64-suse-linux Thread model: posix Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/4.8 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/5 Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/5 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/5 Candidate multilib: .;@m64 Selected multilib: .;@m64 $ g++ -c zcu.cpp -Wall $ g++ -c zcu.cpp -Wall -std=gnu++11 $ clang++ -c zcu.cpp -Wall $ clang++ -c zcu.cpp -Wall -std=gnu++11 In file included from zcu.cpp:1: In file included from /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/set:60: In file included from /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/stl_tree.h:63: /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/stl_algobase.h:310:18: error: no viable conversion from 'const SOURCEKEY' to 'typename set, less >, allocator > >::value_type' (aka 'std::__cxx11::basic_string') *__result = *__first; ^~~~ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/stl_algobase.h:400:36: note: in instantiation of function template specialization 'std::__copy_move::__copy_m, std::insert_iterator, std::less >, std::allocator > > > >' requested here _Category>::__copy_m(__first, __last, __result); ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/stl_algobase.h:436:23: note: in instantiation of function template specialization 'std::__copy_move_a, std::insert_iterator, std::less >, std::allocator > > > >' requested here return _OI(std::__copy_move_a<_IsMove>(std::__niter_base(__first), ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/stl_algobase.h:468:20: note: in instantiation of function template specialization 'std::__copy_move_a2, std::insert_iterator, std::less >, std::allocator > > > >' requested here return (std::__copy_move_a2<__is_move_iterator<_II>::__value> ^ zcu.cpp:20:7: note: in instantiation of function template specialization 'std::copy, std::insert_iterator, std::less >, std::allocator > > > >' requested here std::copy(setFolders.begin(), setFolders.end(), std::inserter(setIds, setIds.begin())); ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/basic_string.h:399:7: note: candidate constructor not viable: no known conversion from 'const SOURCEKEY' to 'const std::__cxx11::basic_string &' for 1st argument basic_string(const basic_string& __str) ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/basic_string.h:455:7: note: candidate constructor not viable: no known conversion from 'const SOURCEKEY' to 'const char *' for 1st argument basic_string(const _CharT* __s, const _Alloc& __a = _Alloc()) ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/basic_string.h:477:7: note: candidate constructor not viable: no known conversion from 'const SOURCEKEY' to 'std::__cxx11::basic_string &&' for 1st argument basic_string(basic_string&& __str) noexcept ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/basic_string.h:504:7: note: candidate constructor not viable: no known conversion from 'const SOURCEKEY' to 'initializer_list' for 1st argument basic_string(initializer_list<_CharT> __l, const _Alloc& __a = _Alloc()) ^ zcu.cpp:11:2: note: candidate function operator unsigned char *() const; ^ zcu.cpp:12:2: note: candidate function operator const std::string () const; ^ /usr/bin/../lib64/gcc/x86_64-suse-linux/5/../../../../include/c++/5/bits/stl_iterator.h:659:51: note: passing argument to parameter '__value' here operator=(typena
[llvm-bugs] [Bug 26362] clang 3.8.0.rc1 fails to build with gcc 4.8.1
https://llvm.org/bugs/show_bug.cgi?id=26362 Igor Sugak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Igor Sugak --- The patch is in. I was able to successfully build with gcc-4.8.1 both on master and release_38. -- 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 26362, which changed state. Bug 26362 Summary: clang 3.8.0.rc1 fails to build with gcc 4.8.1 https://llvm.org/bugs/show_bug.cgi?id=26362 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 26453] Regression(259616:259623): Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr while building chromium
https://llvm.org/bugs/show_bug.cgi?id=26453 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Smith --- Please reopen if this is still broken after r259677. -- 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 26441] TestConsecutiveBreakpoints.test_single_step_thread_specific fails on OSX
https://llvm.org/bugs/show_bug.cgi?id=26441 Jim Ingham changed: What|Removed |Added Status|NEW |RESOLVED CC||jing...@apple.com Resolution|--- |FIXED --- Comment #2 from Jim Ingham --- Fixed in r259684. -- 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 23840] SFINAE failure with variadic non-type template parameter
https://llvm.org/bugs/show_bug.cgi?id=23840 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Fixed in r259688. -- 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 26460] New: int3 __builtin_astype(x, short8) asserts for OpenCL
https://llvm.org/bugs/show_bug.cgi?id=26460
Bug ID: 26460
Summary: int3 __builtin_astype(x, short8) asserts for OpenCL
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: pjc...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
For this file:
typedef int int3 __attribute__((ext_vector_type(3)));
typedef short short8 __attribute((ext_vector_type(8)));
int get(short8 x) {
int3 y = __builtin_astype(x, int3);
return y[0];
}
clang -S -emit-llvm -x cl hits the following assert:
/home/peter/llvm/llvm-trunk-git/llvm/lib/IR/Instructions.cpp:2572: static
llvm::CastInst* llvm::CastInst::Create(llvm::Instruction::CastOps,
llvm::Value*, llvm::Type*, const llvm::Twine&, llvm::Instruction*): Assertion
`castIsValid(op, S, Ty) && "Invalid cast!"' failed.
int3 <-> int4 __builtin_astype works, as does short8 <-> int4.
--
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 26373] [WinEH] LSR asserts trying to insert instructions at a catchswitch
https://llvm.org/bugs/show_bug.cgi?id=26373 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Component|new bugs|Loop Optimizer Resolution|--- |FIXED Assignee|andrew.kay...@intel.com |david.majne...@gmail.com Product|new-bugs|libraries --- Comment #12 from David Majnemer --- Fixed in r259702. -- 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 26461] New: Bogus '-avx512ifma' is not a recognized feature for this target (ignoring feature)
https://llvm.org/bugs/show_bug.cgi?id=26461
Bug ID: 26461
Summary: Bogus '-avx512ifma' is not a recognized feature for
this target (ignoring feature)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: octopl...@yandex.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
markus@x4 ~ % echo 'int main(){}' | clang++ -o /dev/null -x c++ -march=native
-
'-avx512ifma' is not a recognized feature for this target (ignoring feature)
'-avx512ifma' is not a recognized feature for this target (ignoring feature)
'-avx512ifma' is not a recognized feature for this target (ignoring feature)
'-avx512ifma' is not a recognized feature for this target (ignoring feature)
'-avx512ifma' is not a recognized feature for this target (ignoring feature)
This happens on an amdfam10 machine.
--
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 26462] New: GCC/clang C11 _Atomic incompatibility
https://llvm.org/bugs/show_bug.cgi?id=26462
Bug ID: 26462
Summary: GCC/clang C11 _Atomic incompatibility
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: jykni...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang and GCC have incompatible ABIs for _Atomic, on non-power-of-2-sized
types.
Simple demonstration of the difference:
struct A3 { char val[3]; };
_Atomic struct A3 a3;
// GCC:
_Static_assert(sizeof(a3) == 3, "");
_Static_assert(_Alignof(a3) == 1, "");
// Clang:
_Static_assert(sizeof(a3) == 4, "");
_Static_assert(_Alignof(a3) == 4, "");
GCC's logic for _Atomic is: For types which have a size of exactly 1, 2, 4, 8,
or 16 bytes, increase the alignment to be at least the size. Never change the
size of the type.
libstdc++'s std::atomic uses the same logic as GCC, but it's implemented inline
in the header, as GCC doesn't support C11 atomics in C++ mode. Thus, libstdc++
under clang also uses GCC's rule.
Clang has the following rule: if the size of a type is less than a
target-specific variable "MaxAtomicPromoteWidth" (0, 4, 8, or 16 bytes on
current targets), round the size up to the next power of two, and SET the
alignment to the size.
libc++'s std::atomic uses clang's C11 atomics support (which clang supports as
an extension in C++ mode), and thus gets the same behavior...but only when
built with clang. When libc++ is built with GCC, it uses an alternative
implementation which doesn't ever increase the alignment/size.
So, the current situation:
- C11 _Atomic is incompatible between Clang and GCC.
- libstdc++'s std::atomic is compatible between Clang and GCC.
- libc++'s std::atomic is incompatible between Clang and GCC.
Furthermore, I believe C11 and C++ atomics are intended to be compatible with
eachother. And that's not true with clang and libstdc++, nor with gcc and
libc++.
--
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 26307] r258705 introduces a crash in computeKnownBits
https://llvm.org/bugs/show_bug.cgi?id=26307 Matthew Simpson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26463] New: Run-time assert while building Chromium
https://llvm.org/bugs/show_bug.cgi?id=26463 Bug ID: 26463 Summary: Run-time assert while building Chromium Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: x...@microsoft.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified In my recent attempt to recollect updated Chrome build data on Mac, chrome starts to fail to build (both out/Release and out/Debug) with additional throughput data collection switch “-ftime-report” due to multiple occurrence of assertion below: Assertion failed: (!Running && "Cannot start a running timer"), function startTimer, file /Users/thakis/src/chrome/src/third_party/llvm/lib/Support/Timer.cpp, line 139. Chrome build.ninja (with additional switches), build failure logs, and automatically created standalone repros are attached/pasted below. Note this only repros with “-ftime-report” switch set – chrome builds successfully on Mac without modifications on build.ninja. But I need that switch to collect throughput data. For some reason, the assertion didn’t repro when I ran those automatically created repro scripts in their folder /var/folders/8z/77mjhj5j6592xmd2_wq53wrwgn/T/. It might because it is some timing sensitive bug - like perhaps the compiler can't create a timer if there are too many other compilers running in parallel？ Modified build commands (in build.ninja file), and one occurrence of that assertion in Chrome build log are pasted below: Additional switch added to build.ninja (full file attached): rule cc command = $cc -MMD -MF $out.d $defines $includes $cflags $cflags_c -ftime-report $cflags_pch_c -c $in -o $out description = CC $out depfile = $out.d deps = gcc rule cc_s command = $cc $defines $includes $cflags $cflags_c -ftime-report $cflags_pch_c -c $in -o $out description = CC $out rule cxx command = $cxx -MMD -MF $out.d $defines $includes $cflags $cflags_cc -ftime-report $cflags_pch_cc -c $in -o $out description = CXX $out depfile = $out.d deps = gcc rule objc command = $cc -MMD -MF $out.d $defines $includes $cflags $cflags_objc -ftime-report $cflags_pch_objc -c $in -o $out description = OBJC $out depfile = $out.d deps = gcc rule objcxx command = $cxx -MMD -MF $out.d $defines $includes $cflags $cflags_objcc -ftime-report $cflags_pch_objcc -c $in -o $out description = OBJCXX $out depfile = $out.d deps = gcc Failure part of build log (full log is too large to be attached) [7349/20094] CXX obj/sdch/open-vcdiff/src/sdch.codetable.o [7350/20094] CXX obj/sdch/open-vcdiff/src/sdch.decodetable.o FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/sdch/open-vcdiff/src/sdch.addrcache.o.d -DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORE=0 -DCHROMIUM_BUILD -DCR_CLANG_REVISION=257955-1 -DUSE_LIBJPEG_TURBO=1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS -DENABLE_HIDPI=1 -DDONT_EMBED_BUILD_METADATA -DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PDF=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DOPEN_VCDIFF_USE_AUTO_PTR -DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_FORTIFY_SOURCE=2 -Igen -I../../sdch/open-vcdiff/src -I../../sdch/mac -I../.. -I../../third_party/zlib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -O2 -gdwarf-2 -fvisibility=hidden -Werror -mmacosx-version-min=10.6 -arch x86_64 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-selector-type-mismatch -Wpartial-availability -Wheader-hygiene -Wfor-loop-analysis -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-deprecated-register -Wno-inconsistent-missing-override -Wno-shift-negative-value -std=c++11 -stdlib=libc++ -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -fno-threadsafe-statics -Xclang -load -Xclang /Users/peptest/tp/chromium/src/third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plu
[llvm-bugs] [Bug 26464] New: Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed on xmlparse.c
https://llvm.org/bugs/show_bug.cgi?id=26464
Bug ID: 26464
Summary: Assertion `!isNull() && "Cannot retrieve a NULL type
pointer"' failed on xmlparse.c
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: lon...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15818
--> https://llvm.org/bugs/attachment.cgi?id=15818&action=edit
zip file containing source file, sh script and log.
I could reproduce the issue on a small sample:
#define poolChop(pool) ((void)--(pool->ptr))
typedef struct {
char *ptr;
} STRING_POOL;
int main(void) {
STRING_POOL apool = {"abcd"};
STRING_POOL *pool = &apool;
poolChop(pool);
return 0;
}
This was compiling OK on Monday, but fails this morning. Changing to ((void)
(--(pool->ptr))) is a work-around.
clang-3.9:
/x/eng/build8/scratch/laurentn/llvm-play/sources/llvm_netapp_integration_prod2/llvm/tools/clang/include/clang/AST/Type.h:589:
const clang::ExtQualsTypeCommonBase *clang::QualType::getCommonPtr() const:
Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed.
0 clang-3.9 0x00f7b098
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 clang-3.9 0x00f79876 llvm::sys::RunSignalHandlers() + 54
2 clang-3.9 0x00f7b77a
3 libpthread.so.0 0x7f787184caa0
4 libc.so.6 0x7f7870b4e22b gsignal + 59
5 libc.so.6 0x7f7870b4f6e8 abort + 328
6 libc.so.6 0x7f7870b46e7f __assert_fail + 223
7 clang-3.9 0x01e073d3 clang::Sema::BuildUnaryOp(clang::Scope*,
clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*) + 867
8 clang-3.9 0x01a89b48 clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 488
9 clang-3.9 0x01a90cb8
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool,
bool, clang::OpaquePtr&, clang::SourceLocation&) + 7320
10 clang-3.9 0x01a89e58 clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 1272
11 clang-3.9 0x01a86bfc
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 156
12 clang-3.9 0x01a8f8df
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool,
bool, clang::OpaquePtr&, clang::SourceLocation&) + 2239
13 clang-3.9 0x01a89e58 clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 1272
14 clang-3.9 0x01a86bfc
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 156
15 clang-3.9 0x01a86b49
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9
16 clang-3.9 0x01acd5c9 clang::Parser::ParseExprStatement() + 41
17 clang-3.9 0x01acc83c
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&) + 1532
18 clang-3.9 0x01acc1b1
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*) + 145
19 clang-3.9 0x01ad3a94
clang::Parser::ParseCompoundStatementBody(bool) + 1780
20 clang-3.9 0x01ad43dc
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 428
21 clang-3.9 0x01a45a02
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
2162
22 clang-3.9 0x01a5dc5b
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2603
23 clang-3.9 0x01a44fa6
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 790
24 clang-3.9 0x01a44970
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 416
25 clang-3.9 0x01a4374a
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1642
26 clang-3.9 0x01a42fcc
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 540
27 clang-3.9 0x01a3eb26 clang::ParseAST(clang::Sema&, bool, bool)
+ 518
28 clang-3.9 0x013d79c5 clang::FrontendAction::Execute() + 69
29 clang-3.9 0x013a3a41
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1153
30 clang-3.9 0x014561db
clang::ExecuteCompilerInvocation(clang::Co
[llvm-bugs] [Bug 26464] Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed on xmlparse.c
https://llvm.org/bugs/show_bug.cgi?id=26464 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from David Majnemer --- *** This bug has been marked as a duplicate of bug 26453 *** -- 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 26465] New: [InstCombine] Replacing ((xor A, B) != 0) with (A != B) is not always good
https://llvm.org/bugs/show_bug.cgi?id=26465 Bug ID: 26465 Summary: [InstCombine] Replacing ((xor A, B) != 0) with (A != B) is not always good Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: t...@fb.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified InstCombiner::visitICmpInstWithInstAndIntCst replaces ((xor A, B) != 0) with (A != B). However, this replacement generates suboptimal code if xor has uses other than the compare. *** Example code ... char c = lhs ^ rhs; if (k == 0) return true; if (k != 32) return false; ... *** What LLVM generates now movzbl (%rbx),%eax movzbl %r8b,%ecx cmp%ecx,%eax je 400c50 mov%r8b,%cl xor%al,%cl movzbl %cl,%ecx cmp$0x20,%ecx jne400cb0 *** What LLVM generates if the replacement performed only when xor has one use mov(%rbx),%al mov%r13b,%cl xor%al,%cl je 400c48 movzbl %cl,%ecx cmp$0x20,%ecx jne400ca0 -- 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 26467] New: Assertion `Success && "failed to evaluate label difference as absolute"' failed.
https://llvm.org/bugs/show_bug.cgi?id=26467
Bug ID: 26467
Summary: Assertion `Success && "failed to evaluate label
difference as absolute"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: MC
Assignee: unassignedb...@nondot.org
Reporter: pe...@pcc.me.uk
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat gzread.i
a;
fn1() {
if (a)
fn2();
}
fn3() {
do
fn1();
while (fn3);
}
fn4() {}
$ ~/src/llvm/ra/bin/clang "-cc1" "-triple" "x86_64-pc-windows-msvc18.0.0"
"-emit-obj" "-mincremental-linker-compatible" "-disable-free" "-main-file-name"
"gzread.i" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix"
"-relaxed-aliasing" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases"
"-munwind-tables" "-target-cpu" "x86-64" "-D_MT" "--dependent-lib=libcmt"
"--dependent-lib=oldnames" "-fno-rtti-data" "-gcodeview" "-fms-volatile"
"-fdiagnostics-format" "msvc" "-momit-leaf-frame-pointer" "-gcodeview"
"-dwarf-column-info" "-debug-info-kind=line-tables-only" "-debugger-tuning=gdb"
"-ffunction-sections" "-O2" "-Wno-unused-parameter"
"-Wno-deprecated-declarations" "-Wall" "-Werror" "-Wno-unused-parameter"
"-Wno-missing-field-initializers" "-Wno-microsoft-enum-value"
"-Wno-unknown-pragmas" "-Wno-microsoft-cast" "-Wheader-hygiene"
"-Wno-char-subscripts" "-Wno-unneeded-internal-declaration"
"-Wno-covered-switch-default" "-Wstring-conversion" "-Wno-c++11-narrowing"
"-Wno-deprecated-register" "-Wno-inconsistent-missing-override"
"-Wno-shift-negative-value" "-Wno-incompatible-pointer-types"
"-Wno-unused-variable" "-w" "-ferror-limit" "19" "-fmessage-length" "0"
"-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=18.0"
"-fno-threadsafe-statics" "-fdelayed-template-parsing" "-fobjc-runtime=gcc"
"-fdiagnostics-show-option" "-vectorize-loops" "-vectorize-slp" "-o"
"gzread.obj" "-x" "cpp-output" "gzread.i"
clang: ../lib/MC/MCCodeView.cpp:249: unsigned int
computeLabelDiff(llvm::MCAsmLayout &, const llvm::MCSymbol *, const
llvm::MCSymbol *): Assertion `Success && "failed to evaluate label difference
as absolute"' failed.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26467] Assertion `Success && "failed to evaluate label difference as absolute"' failed.
https://llvm.org/bugs/show_bug.cgi?id=26467 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Should be fixed by r259733. -- 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 26388] Run ubsan and lld tests on a Windows bot on the llvm waterfall
https://llvm.org/bugs/show_bug.cgi?id=26388 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Rui Ueyama --- It should have been fixed by r259584. -- 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 26468] New: -Wuninitialized warning on empty struct
https://llvm.org/bugs/show_bug.cgi?id=26468
Bug ID: 26468
Summary: -Wuninitialized warning on empty struct
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: hjl.to...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
[hjl@gnu-6 empty-2]$ cat x.c
struct empty {};
struct empty
foo (void)
{
struct empty s;
return s;
}
[hjl@gnu-6 empty-2]$ make
/export/build/gnu/llvm-clang-bootstrap/stage1/build-x86_64-linux/bin/clang -m32
-S -O -Wall x.c
x.c:7:10: warning: variable 's' is uninitialized when used here
[-Wuninitialized]
return s;
^
x.c:6:3: note: variable 's' is declared here
struct empty s;
^
1 warning generated.
[hjl@gnu-6 empty-2]$
Shouldn't empty struct be a special case 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 26469] New: [Polly] www: Inside Polly documentation is outdated
https://llvm.org/bugs/show_bug.cgi?id=26469 Bug ID: 26469 Summary: [Polly] www: Inside Polly documentation is outdated Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Website Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified The commands at http://polly.llvm.org/example_manual_matmul.html are outdated and need to be updated as well as the relevant files in www/examples/matmul. -- 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 26470] New: [www] Build doxygen documentation for Polly and add it to website
https://llvm.org/bugs/show_bug.cgi?id=26470 Bug ID: 26470 Summary: [www] Build doxygen documentation for Polly and add it to website Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Website Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 26471] New: [Polly] Start writing sphinx documentation for Polly
https://llvm.org/bugs/show_bug.cgi?id=26471 Bug ID: 26471 Summary: [Polly] Start writing sphinx documentation for Polly Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- 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
