[llvm-bugs] [Bug 26519] Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result)
https://llvm.org/bugs/show_bug.cgi?id=26519 Krzysztof Parzyszek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Krzysztof Parzyszek --- Committed in r280705. -- 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 26519, which changed state. Bug 26519 Summary: Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) https://llvm.org/bugs/show_bug.cgi?id=26519 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 30289] crash at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes (Assertion `!(DivIsSigned && C2->isAllOnesValue()) && "The overflow computation will fail."' failed.)
https://llvm.org/bugs/show_bug.cgi?id=30289 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED See Also||https://llvm.org/bugs/show_ ||bug.cgi?id=30281 Resolution|--- |FIXED --- Comment #1 from Sanjay Patel --- This is a very similar bug/fix to bug 30281. It should be solved after: https://reviews.llvm.org/rL280677 -- 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 30282, which changed state. Bug 30282 Summary: Linking FreeBSD i386 library with lld fails with "can't create dynamic relocation R_386_GOTOFF against readonly segment" https://llvm.org/bugs/show_bug.cgi?id=30282 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 30282] Linking FreeBSD i386 library with lld fails with "can't create dynamic relocation R_386_GOTOFF against readonly segment"
https://llvm.org/bugs/show_bug.cgi?id=30282 Rafael Ávila de Espíndola changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r280709. -- 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 30243] Add support for the FILL command
https://llvm.org/bugs/show_bug.cgi?id=30243 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from George Rimar --- Implemented in r280708 -- 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 30291] New: clang failed to parse a template type when with multi-inheritanced lambda objects
https://llvm.org/bugs/show_bug.cgi?id=30291 Bug ID: 30291 Summary: clang failed to parse a template type when with multi-inheritanced lambda objects Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangb...@nondot.org Reporter: wang_f...@live.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17214 --> https://llvm.org/bugs/attachment.cgi?id=17214&action=edit sample code The attached code works well with clang++, when the `struct overloader` is defined in a namespace; however, if I remove this structure out of the namespace, the compilation will go wrong. + worked within namespace -- http://melpon.org/wandbox/permlink/sZlVjyM28BySF6CM + not worked outside a namespace -- http://melpon.org/wandbox/permlink/oKfH154NXqKsN5Ic -- 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 30292] New: infinite loop (?) in -simplifycfg
https://llvm.org/bugs/show_bug.cgi?id=30292 Bug ID: 30292 Summary: infinite loop (?) in -simplifycfg Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: will...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17215 --> https://llvm.org/bugs/attachment.cgi?id=17215&action=edit bitcode demonstrating bug, from libevent Encountered this starting about a week ago on trunk, occurred when building libevent. With the attached bc file: $ opt event.bc -simplifycfg -disable-output -debug-pass=Executions ... [2016-09-06 09:38:06.956737000] 0x3838f10 Executing Pass 'Simplify the CFG' on Function 'event_base_loop'... And it proceeds to never complete this pass (hours+). I'm not sure what the best way to reduce a timing-related bug is, apologies for the non-reduced test-case. Even getting this bitcode was more trouble than I expected (tips welcome, is there a better way?): I ended up using -print-before=simplifycfg and kludging the function printing pass to dump the entire module instead. LMK if you have any questions or problems reproducing on trunk, thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30291] clang failed to parse a template type when with multi-inheritanced lambda objects
https://llvm.org/bugs/show_bug.cgi?id=30291 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- In the second case, the name 'overloader' refers to the function parameter not the class template. -- 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 30293] New: clang-cl miscompilation of Firefox's netwerk/base/nsSocketTransportService2.cpp
https://llvm.org/bugs/show_bug.cgi?id=30293
Bug ID: 30293
Summary: clang-cl miscompilation of Firefox's
netwerk/base/nsSocketTransportService2.cpp
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: froy...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17216
--> https://llvm.org/bugs/attachment.cgi?id=17216&action=edit
preprocessed source and runscript
While debugging why Firefox crashes when compiled with clang-cl, I ran across
this miscompilation. In nsSocketTransport2.cpp, we have:
nsSocketTransportService* gSocketTransportService = nullptr;
...
void
nsSocketTransportService::OnKeepaliveEnabledPrefChange()
{
// Dispatch to socket thread if we're not executing there.
if (PR_GetCurrentThread() != gSocketThread) {
gSocketTransportService->Dispatch(
NewRunnableMethod(
this, &nsSocketTransportService::OnKeepaliveEnabledPrefChange),
nsIEventTarget::DISPATCH_NORMAL);
return;
}
...
}
The preprocessed source file, along with the command-line flags used to compile
it, are provided in the attached tarball. What I see happening in the debugger
running Firefox is:
1. At the start of OnKeepaliveEnabledPrefChange, ecx contains |this|, and so
does gSocketTransportService.
2. When we load from gSocketTransportService, we adjust its value by 4.
3. When we're preparing to call Dispatch, I think the code is assembling a
member function pointer to be used with some kind of thunk. Whatever it's
doing, the adjusted value we constructed in step (2) winds up in 0(%ecx)
3. When Dispatch() is invoked, we go through what looks like a thunk, but none
of the arguments are massaged in any way; the thunk jumps directly to the
Dispatch() implementation. (I think this is a thunk, anyway; it doesn't appear
in llvm-objdump -d output, but it's definitely there in the debugger, for
reasons I do not understand.)
4. The real Dispatch implementation receives the adjusted pointer from step (3)
in 0(%ecx), acts on it as though it's the actual |this| pointer and things go
south from there. We call nsSocketTransportService::GetThreadSafely() with the
wrong |this| value and it loads a null pointer instead of the actual pointer
it's supposed to load.
--
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 30294] New: Typo in CMakeLists.txt "LLVM_INCLDE_TESTS"
https://llvm.org/bugs/show_bug.cgi?id=30294 Bug ID: 30294 Summary: Typo in CMakeLists.txt "LLVM_INCLDE_TESTS" Product: Build scripts Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: alfedo...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified There is a typo in CMakeLists.txt LLVM_INCLDE_TESTS if ( LLVM_INCLUDE_TESTS ) message(FATAL_ERROR "Including tests when not building utils will not work. Either set LLVM_INCLUDE_UTILS to On, or set LLVM_INCLDE_TESTS to Off.") Should be LLVM_INCLUDE_TESTS -- 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 30295] New: test infra: consider storing and re-using test inferior build artifacts for a given test directory
https://llvm.org/bugs/show_bug.cgi?id=30295 Bug ID: 30295 Summary: test infra: consider storing and re-using test inferior build artifacts for a given test directory Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As brought up in llvm.org/pr30271 (https://llvm.org/bugs/show_bug.cgi?id=30271): Pavel had the idea of re-using build artifacts across test methods and test files in a given test directory. This likely would increase the speed with which we could run the test suite as it eliminates the need to rebuild test inferiors for any test that includes more than one test method. My further comments from pr30271: 8< > We could achieve a big speedup by just not re-building the binaries over and > over again. I could see that being a really big win. We'd have to parameterize the memoization of the built artifacts by anything that could change. These would include: * make command line * environment variables I think that already covers the compilers, as they would be specified by CC/CXX env vars or command line parameters to make. We'd need a concept of the build artifacts for a given set of build settings. We could conceivably allow these to be stored in a specified directory, which could allow builders to preserve them across clean builds of the lldb product if we so desired. (We might not want that, so that a clean build is really a clean build of the test artifacts as well). We could figure out that later. I think this is a very worthwhile item to investigate. I don't know if/how this impacts what we would do if we used lit to run our tests. (As I mentioned on a different thread, I have not yet put any effort into looking at what our test suite would look like running existing tests in that test runner. We currently have a number of assumptions about how our build process interacts with test method runs that may or may not fit into the lit expectations as they currently stand. Zach mentioned we could write some kind of test runner that plugs into lit, which maybe can handle these details. In that case, the effort for your suggestion could be easily lifted and used in both scenarios, and therefore wouldn't be a waste of effort if we switched test runners). 8< -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30296] New: Merge r279871 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30296 Bug ID: 30296 Summary: Merge r279871 into the 3.9 branch Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: renato.go...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is a small bug fix that makes it work when compiling to specific architectures and has no impact whatsoever on other than make it compile. -- 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 30297] New: Merge r280599 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30297 Bug ID: 30297 Summary: Merge r280599 into the 3.9 branch Product: new-bugs Version: 3.9 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mehdi.am...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Fix ThinLTO crash with debug info Because the recent change about ODR type uniquing in the context, we can reach types defined in another module during IR linking. This triggered some assertions in case we IR link without starting from an empty module. To alleviate that, we can self-map metadata defined in the destination module so that they won't be visited. Differential Revision: https://reviews.llvm.org/D23841 -- 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 30298] New: Compiling libx264 (target-cpu i686 +sse): Do not know how to custom type legalize this operation!
https://llvm.org/bugs/show_bug.cgi?id=30298
Bug ID: 30298
Summary: Compiling libx264 (target-cpu i686 +sse): Do not know
how to custom type legalize this operation!
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Building libx264 from the FreeBSD ports collection with clang 3.9.0 release, on
a 32-bit host, enabling SSE, results in:
clang -Wshadow -O3 -ffast-math -m32 -O2 -pipe -isystem /usr/local/include
-fstack-protector -fno-strict-aliasing -Wall -I. -I. -isystem
/usr/local/include -O2 -pipe -isystem /usr/local/include -fstack-protector
-fno-strict-aliasing -march=i686 -mfpmath=sse -msse -std=gnu99
-fomit-frame-pointer -fno-tree-vectorize -isystem /usr/local/include -c -o
common/pixel.o common/pixel.c
Do not know how to custom type legalize this operation!
UNREACHABLE executed at
/share/dim/src/freebsd/base/projects/clang390-import/contrib/llvm/lib/Target/X86/X86ISelLowering.cpp:21834!
This also occurs with trunk r280722, but not with 3.8.0 release, so it a
regression.
Minimized test case:
// clang -cc1 -triple i386 -S -target-cpu i686 -target-feature +sse -O2 -w
-vectorize-slp testcase.c
char *a, *b;
e;
static fn1(long long *p1, long long *p2) {
for (;;) {
int c = a[0] - b[0], d = a[1] - b[1];
*p1 += c * c;
*p2 += d * d;
}
}
fn2() { fn1(fn2, &e); }
--
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 30299] New: TestDarwinLogFilterRegexMessage tests sometimes fail
https://llvm.org/bugs/show_bug.cgi?id=30299 Bug ID: 30299 Summary: TestDarwinLogFilterRegexMessage tests sometimes fail Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified One of my darwin log test files (testing regex matching on full log message content) is flaky. It's not just one test method; rather, it is several. Mark them XFAIL, then investigate the 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 30245] Compiler-rt linking broken
https://llvm.org/bugs/show_bug.cgi?id=30245 Eugene Zelenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eugene Zelenko --- Works for me. Thank you for help! -- 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@lists.llvm.org
https://llvm.org/bugs/show_bug.cgi?id=30300 Bug ID: 30300 Summary: [3.9.1 Merge] r279955 Fix pair::operator=(TupleLike&&). Product: libc++ Version: 3.8 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified This assignment operator was previously broken since the SFINAE always resulted in substitution failure. This caused assignments to turn into copy construction + assignment. -- 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 30272] clang-analyzer-unix.MismatchedDeallocator issues with custom operator delete
https://llvm.org/bugs/show_bug.cgi?id=30272 Eugene Zelenko changed: What|Removed |Added CC||eugene.zele...@gmail.com, ||llvm-bugs@lists.llvm.org Component|clang-tidy |Static Analyzer Assignee|unassignedclangbugs@nondot. |kreme...@apple.com |org | Product|clang-tools-extra |clang -- 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 30301] New: [3.9.1 Merge] r280190 - PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization.
https://llvm.org/bugs/show_bug.cgi?id=30301 Bug ID: 30301 Summary: [3.9.1 Merge] r280190 - PR12298 et al: don't recursively instantiate a template specialization from within the instantiation of that same specialization. Product: clang Version: 3.9 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. This commit is needed to fix: - http://llvm.org/PR12298 - http://llvm.org/PR29123 -- 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 28946] crash at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Assertion `(KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?"' failed.)
https://llvm.org/bugs/show_bug.cgi?id=28946 Li Huang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Li Huang --- Fixed by r279684. Thanks, Li Huang -- 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 30302] New: numpunt_byname and moneypunct_byname cannot represent multibyte decimal_point or thousands_sep.
https://llvm.org/bugs/show_bug.cgi?id=30302 Bug ID: 30302 Summary: numpunt_byname and moneypunct_byname cannot represent multibyte decimal_point or thousands_sep. Product: libc++ Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified The virtual functions they use to return the separators only return a single character. If the requested locale uses multibyte separators then these facets have no way to represent those. For example ru_RU.UTF-8 uses \u00A0 as the thousands_sep on glibc. Unfortunatly libc++ can only return the first byte of that when the underlying char_type is 'char'. The first byte is 0xC2 which ends up creating an invalid utf-8 string. This probably requires a LWG issue and a fix in the standard. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006 -- 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 30276] PowerPC64: Code hits "Impossible reg-to-reg copy" assertion
https://llvm.org/bugs/show_bug.cgi?id=30276 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hal Finkel --- Fixed by r280767. -- 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 30303] New: error: no matching function for call to '__ptr_in_range'
https://llvm.org/bugs/show_bug.cgi?id=30303
Bug ID: 30303
Summary: error: no matching function for call to
'__ptr_in_range'
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com,
mc...@qti.qualcomm.com
Classification: Unclassified
The following code used to compile, but now fails as below. This is reduced
from some code in Chromium.
#include
#include
#include
using namespace std;
void f(string &s, vector &v) {
s.append(v.begin(), v.end());
}
In file included from /tmp/a.cc:1:
/work/llvm/build.release/bin/../include/c++/v1/string:2180:14: error: no
matching function for call to '__ptr_in_range'
if ( __ptr_in_range(&*__first, data(), data() + size()))
^~
/tmp/a.cc:7:5: note: in instantiation of function template specialization
'std::__1::basic_string,
std::__1::allocator >::append >'
requested here
s.append(v.begin(), v.end());
^
/work/llvm/build.release/bin/../include/c++/v1/string:2160:6: note: candidate
template ignored: deduced conflicting types for parameter '_Tp' ('unsigned
char' vs. 'char')
bool __ptr_in_range (const _Tp* __p, const _Tp* __first, const _Tp* __last)
^
1 error generated.
I believe this is due to:
r280643 | marshall | 2016-09-04 18:54:30 -0700 (Sun, 04 Sep 2016) | 1 line
Fix Bug 30240 - std::string: append(first, last) error when aliasing. Add test
cases for append/insert/assign/replace while we're at it, and fix a similar bug
in insert.
--
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 25658] CAS is created unconditionally for 32bit SPARC
https://llvm.org/bugs/show_bug.cgi?id=25658 James Y Knight changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from James Y Knight --- The behavior problem is now fixed, although I still need to finish cleaning up the 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 30303] error: no matching function for call to '__ptr_in_range'
https://llvm.org/bugs/show_bug.cgi?id=30303 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marshall Clow (home) --- Committed revision 280779 to fix 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 30304] New: Combination of BreakBeforeBinaryOperators: All, AlignAfterOpenBracket: AlwaysBreak doesn't handling long template parameter list.
https://llvm.org/bugs/show_bug.cgi?id=30304
Bug ID: 30304
Summary: Combination of BreakBeforeBinaryOperators: All,
AlignAfterOpenBracket: AlwaysBreak doesn't handling
long template parameter list.
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: daphnedi...@mac.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17217
--> https://llvm.org/bugs/attachment.cgi?id=17217&action=edit
Simplified sample code that does not format correctly.
When both BreakBeforeBinaryOperators: All and AlignAfterOpenBracket:
AlwaysBreak formatting options are specified clang-format does not wrap really
long template lines.
I've attached a sample file that can show the problem.
The default works:
clang-format --style='{BasedOnStyle: llvm, BreakBeforeBinaryOperators: None,
AlignAfterOpenBracket: Align}' dummy.cxx
Changing BBBO to all but leaving AAOB as default also works.
clang-format --style='{BasedOnStyle: llvm, BreakBeforeBinaryOperators: All,
AlignAfterOpenBracket: Align}' dummy.cxx
Changing AAOB to AlwaysBreak but leaving BBBO as default also works.
clang-format --style='{BasedOnStyle: llvm, BreakBeforeBinaryOperators: None,
AlignAfterOpenBracket: AlwaysBreak}' dummy.cxx
But turning on both at once falls to wrap the line
clang-format --style='{BasedOnStyle: llvm, BreakBeforeBinaryOperators: All,
AlignAfterOpenBracket: AlwaysBreak}' dummy.cxx
--
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
