[llvm-bugs] [Bug 33999] New: Double destruction of object created in for loop condition
https://bugs.llvm.org/show_bug.cgi?id=33999
Bug ID: 33999
Summary: Double destruction of object created in for loop
condition
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: stephane.zimmerm...@trust-in-soft.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The following code:
extern "C" int printf(const char *, ...);
struct Foo {
Foo() {
printf("CONSTRUCTOR\n");
}
~Foo() {
printf("DESTRUCTOR\n");
}
operator bool() {
static int guard = 0;
++guard;
return guard < 3;
}
};
int main(void) {
for( ; Foo f {}; 0)
continue;
}
displays:
CONSTRUCTOR
DESTRUCTOR
DESTRUCTOR
CONSTRUCTOR
DESTRUCTOR
DESTRUCTOR
CONSTRUCTOR
DESTRUCTOR
In the two iterations of the loop the object in condition is destroyed two
times. This does not happen if the increment is empty or without the
"continue;" statement.
--
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 21304] Illegal source code compiles without error when PCH is enabled
https://bugs.llvm.org/show_bug.cgi?id=21304 Philip Douglas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||psd+l...@pdouglas.net --- Comment #1 from Philip Douglas --- I am unable to reproduce this problem (the error is reported correctly when compiling with PCH) with Clang 3.6 or 4.0 so I believe it has been 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 34000] New: [feature-request] multi-lib build of libc++
https://bugs.llvm.org/show_bug.cgi?id=34000 Bug ID: 34000 Summary: [feature-request] multi-lib build of libc++ Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: gonzalob...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com When building llvm + clang + ... + libc++ +/- libc++abi "in tree" it would be great to be able to automatically generate multiple builds of libc++: - debug / release - asan+ubsan / msan - ... and have clang use the appropriate build by default so that, e.g., compiling with clang -fsanitize=memory automatically picks the libc++ sanitized with msan, or when compiling with -fsanitize=address automatically picks the libc++ sanitized with asan. -- 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 34001] New: One-line if statement problem
https://bugs.llvm.org/show_bug.cgi?id=34001
Bug ID: 34001
Summary: One-line if statement problem
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: bubyoffic...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Configuration of clang-format:
AllowShortBlocksOnASingleLine: true
AllowShortIfStatementsOnASingleLine: true
BreakBeforeBraces: Custom
BraceWrapping: { AfterClass: true, AfterControlStatement: true, AfterEnum:
true, AfterFunction: true, AfterNamespace: false, AfterStruct: true,
AfterUnion: true, BeforeCatch: true, BeforeElse: true }
Code:
// BEFORE:
if (statement) doSomething();
if (statement) { doSomething(); }
// AFTER:
if (statement) doSomething();
if (statement) {
doSomething();
}
I expected, that clang-format will leave second block of code without changes.
When I don't set BreakBeforeBraces, clang-format works fine, but this property
is required in my project.
Looks like a bug.
--
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 34003] New: Unspecified behavior - 'typedef enum' and 'extern'
https://bugs.llvm.org/show_bug.cgi?id=34003
Bug ID: 34003
Summary: Unspecified behavior - 'typedef enum' and 'extern'
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: bubyoffic...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Unspecified behavior: different formatting rules if there is enum declaration
directly before 'typedef enum' or 'extern'.
Configuration of clang-format.
BraceWrapping: AfterEnum is set to true.
Code:
// BEFORE:
extern "C" {
#include
}
typedef enum { a, b, c } MyEnum;
enum SomeEnum
{
AAA = 1,
BBB = 2,
}
extern "C" {
#include
}
enum SomeEnum
{
AAA = 1,
BBB = 2,
}
typedef enum { a, b, c } MyEnum;
//AFTER:
extern "C" {
#include
}
typedef enum { a, b, c } MyEnum;
enum SomeEnum
{
AAA = 1,
BBB = 2,
}
extern "C"
{
#include
}
enum SomeEnum
{
AAA = 1,
BBB = 2,
}
typedef enum
{
a,
b,
c
} MyEnum;
--
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 34002] New: Assembly Parser Emits .thumb_func and Conditional Instructions Too Late After Function Label
https://bugs.llvm.org/show_bug.cgi?id=34002 Bug ID: 34002 Summary: Assembly Parser Emits .thumb_func and Conditional Instructions Too Late After Function Label Product: libraries Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: edit...@zju.edu.cn CC: llvm-bugs@lists.llvm.org Created attachment 18877 --> https://bugs.llvm.org/attachment.cgi?id=18877&action=edit Original assembly code it-block.S and generated assembly code it-block-roundtrip.s Overview: When parsing a function label, AsmParser emits the .thumb_func directive and closes the open IT block (if one is open right before the function label) too late, so that both the .thumb_func directive and conditional instructions of the IT block are emitted after the function label. Steps to Reproduce: 1) Save the following native assembly code to it-block.S: .text .syntax unified .p2align 1 .code 16 .globl f1 .globl f2 .thumb_func f1: CMP r0, #10 .thumb_func MOVPL r0, #0 f2: MOVS r1, #0 .Ltmp: CMP r0, #0 ITTT PL ADDPL r1, r1, r0 SUBPL r0, r0, #1 BPL .Ltmp MOV r0, r1 BXlr .end 2) Run llvm-mc on it-block.S and ask it to generate native assembly code, using the following command line: llvm-mc -arch=thumb -filetype=asm -mattr=+soft-float,-neon,-crypto,+strict-align -mcpu=cortex-m3 -n -triple=armv7m-none-none-eabi -o=it-block-roundtrip.s it-block.S -arm-implicit-it=always Actual Results: The native assembly code generated by llvm-mc is as follows: .text .p2align1 .code16 .globlf1 .globlf2 f1: .thumb_func cmpr0, #10 f2: itpl movplr0, #0 .thumb_func movsr1, #0 .Ltmp: cmpr0, #0 itttpl addplr1, r1, r0 subplr0, r0, #1 bpl.Ltmp movr0, r1 bxlr Note two types of errors: i. For both function labels f1 and f2, the corresponding .thumb_func directive is after the function label; ii. The movpl instruction, which should be before f2 and is NOT part of function f2, is emitted after f2 and becomes part of function f2. Expected Results: i. For both function labels f1 and f2, the corresponding .thumb_func directive should be before the label; ii. The movepl instruction should be before label f2. Additional information: As the following code snippet copied from lib/MC/MCParser/AsmParser.cpp shows, when parsing a label, AsmParser::parseStatement calls MCTargetAsmParser::onLabelParsed of a target parser after emitting the label: // Emit the label. if (!getTargetParser().isParsingInlineAsm()) Out.EmitLabel(Sym, IDLoc); // If we are generating dwarf for assembly source files then gather the // info to make a dwarf label entry for this label if needed. if (getContext().getGenDwarfForAssembly()) MCGenDwarfLabelEntry::Make(Sym, &getStreamer(), getSourceManager(), IDLoc); getTargetParser().onLabelParsed(Sym); For ARM, calling MCTargetAsmParser::onLabelParsed after emitting the label seems to be the cause of the bug. If I understand it correctly, ARMAsmParser::onLabelParsed (defined in lib/Target/ARM/AsmParser/ARMAsmParser.cpp) performs two tasks: i. Close the current implicit IT block (if one is open for new conditional instructions) BEFORE the label, so that the IT block cannot be entered from the middle of it. ii. Emit a .thumb_func directive, if the label is the first label following a previously parsed .thumb_func directive without an optional symbol. It seems that the two types of errors are direct consequences of calling MCTargetAsmParser::onLabelParsed after emitting the label being parsed. What's more, MCTargetAsmParser::onLabelParsed seems to be only used by the ARM backend. Therefore, in order to fix the bug, it seems sufficient to call MCTargetAsmParser::onLabelParsed before emitting the label being parsed. -- 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 34004] New: [coroutines] PCH / Modules and coroutines do not mix. Need to add serialization/deserialization
https://bugs.llvm.org/show_bug.cgi?id=34004 Bug ID: 34004 Summary: [coroutines] PCH / Modules and coroutines do not mix. Need to add serialization/deserialization Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: gornisha...@gmail.com CC: llvm-bugs@lists.llvm.org -- 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 34004] [coroutines] PCH / Modules and coroutines do not mix. Need to add serialization/deserialization
https://bugs.llvm.org/show_bug.cgi?id=34004 gornisha...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from gornisha...@gmail.com --- Fixed by: https://reviews.llvm.org/D35383 Commit: https://reviews.llvm.org/rL308996 -- 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 34005] New: Compiler confused when compiling template variable initialized by lambda-expression with default parameter.
https://bugs.llvm.org/show_bug.cgi?id=34005
Bug ID: 34005
Summary: Compiler confused when compiling template variable
initialized by lambda-expression with default
parameter.
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: shirayama.kazats...@gmail.com
CC: llvm-bugs@lists.llvm.org
The code below fail to be compile.
// prog.cc
template struct X {};
template constexpr void f(X) {}
template constexpr int v = [](int r = 0l) constexpr { return r; }();
int main() {
f>(X<0>());
}
$ clang++ -std=c++1z prog.cc
prog.cc:6:5: error: no matching function for call to 'f'
f>(X<0>());
^
prog.cc:2:32: note: candidate function not viable: no known conversion from
'X<...>' to 'X<...>' for 1st argument
template constexpr void f(X) {}
^
1 error generated.
I think v is always 0, so f>(X<0>()) should match f<0>(X<0>);
And if lambda's default parameter type is int,
template constexpr int v = [](int r = 0) constexpr { return r; }();
There are no errors.
This link is the result executed by wandbox.
https://wandbox.org/permlink/yjKqrYKQyl2YZ6PO
--
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 33978] "Flags mismatch!" assertion on LLVM 5.0 with MIPS
https://bugs.llvm.org/show_bug.cgi?id=33978 Simon Dardis changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Simon Dardis --- r309561. -- 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 33883] "Part type doesn't match vector breakdown!" assertion when mixing SIMD and MIPS
https://bugs.llvm.org/show_bug.cgi?id=33883 Simon Dardis changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Simon Dardis --- r309561. -- 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 33978] "Flags mismatch!" assertion on LLVM 5.0 with MIPS
https://bugs.llvm.org/show_bug.cgi?id=33978 Simon Dardis changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Simon Dardis --- Argh, closed wrong bug. -- 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 25056] Unable to split UADDV on v8i32
https://bugs.llvm.org/show_bug.cgi?id=25056 Jun Bum Lim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31167] On thin archives llvm-ar display table behavior differs from gnu ar
https://bugs.llvm.org/show_bug.cgi?id=31167 Mark Santaniello 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 33993] Assertion failed: ((Size == 32 || Size == 64) && "i32 or i64 is expected after legalization."), function targetShrinkDemandedConstant
https://bugs.llvm.org/show_bug.cgi?id=33993 Hans Wennborg changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- (In reply to Tim Northover from comment #3) > Looks fine for 5.0 to me. The change is pretty obviously right. Merged in r309586. I also merged the x86 one in r309587. -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33993, which changed state. Bug 33993 Summary: Assertion failed: ((Size == 32 || Size == 64) && "i32 or i64 is expected after legalization."), function targetShrinkDemandedConstant https://bugs.llvm.org/show_bug.cgi?id=33993 What|Removed |Added Status|REOPENED|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 33830] [AVX] clang does not respect streaming store intrinsics
https://bugs.llvm.org/show_bug.cgi?id=33830 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Hans Wennborg --- (In reply to Hans Wennborg from comment #8) > (In reply to Simon Pilgrim from comment #7) > > Fixed in trunk by rL309382 (new tests) and rL309488 (fix) - rL309383 (strip > > trailing white space) hopefully won't be necessary. > > > > Hans - if possible I'd like to get this merged to 5.000 please. > > I've replied on r309488 to ask Craig. Merged them all in r309588. -- 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 34003] Unspecified behavior - 'typedef enum' and 'extern'
https://bugs.llvm.org/show_bug.cgi?id=34003 Patryk Wróbel 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33830, which changed state. Bug 33830 Summary: [AVX] clang does not respect streaming store intrinsics https://bugs.llvm.org/show_bug.cgi?id=33830 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 33987] Please backport OCaml fixes to 5.0 branch
https://bugs.llvm.org/show_bug.cgi?id=33987 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- Merged in r309590, r309591 and r309592, respectively. -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33987, which changed state. Bug 33987 Summary: Please backport OCaml fixes to 5.0 branch https://bugs.llvm.org/show_bug.cgi?id=33987 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33991, which changed state. Bug 33991 Summary: Please revert dependent revisions along with r304835 https://bugs.llvm.org/show_bug.cgi?id=33991 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 33991] Please revert dependent revisions along with r304835
https://bugs.llvm.org/show_bug.cgi?id=33991 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- (In reply to Michał Górny from comment #0) > commit c92d17461853b1f992af5dcef2ca304113ac2f94 > Author: Hans Wennborg > Date: Thu Jul 27 18:21:47 2017 > > Revert r304835: It's not clear printing all targets with --version is > the right thing to do (see discussion on D33900) > > git-svn-id: > https://llvm.org/svn/llvm-project/llvm/branches/release_50@309286 > 91177308-0d34-0410-b5e6-96231b3b80d8 > > > This breaks at least clang-tools-extra where r304837 includes a dependent > change. Thanks! I missed that one. r309593. -- 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 26794] AArch64 schedule models are incomplete
https://bugs.llvm.org/show_bug.cgi?id=26794 Evandro Menezes changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Evandro Menezes --- Solved by r304259. -- 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 34006] New: __msa_fill_w() fails
https://bugs.llvm.org/show_bug.cgi?id=34006
Bug ID: 34006
Summary: __msa_fill_w() fails
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: fbarch...@google.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18879
--> https://bugs.llvm.org/attachment.cgi?id=18879&action=edit
source file fom libyuv row_msa.cc
#define ST_B(RTYPE, in, pdst) *((RTYPE*)(pdst)) = (in) /* NOLINT */
#define ST_UB(...) ST_B(v16u8, __VA_ARGS__)
void ARGBSetRow_MSA(uint8* dst_argb, uint32 v32, int width) {
int x;
v16u8 dst0 = (v16u8)__msa_fill_w(v32);
for (x = 0; x < width; x += 4) {
ST_UB(dst0, dst_argb);
dst_argb += 16;
}
}
This is what gcc produces:
Disassembly of section .text.ARGBSetRow_MSA:
:
0: 7b02281efill.w $w0,a1
4: 102dmovev0,zero
0008 <.L390>:
8: 5846bgecv0,a2,c <.L390+0x4>
c: 78002024st.b$w0,0(a0)
10: 24420004addiu v0,v0,4
14: 1000b 18 <.L390+0x10>
18: 64840010daddiu a0,a0,16
001c <.L394>:
1c: d81fjrc ra
./src/third_party/llvm-build/Release+Asserts/bin/clang --version
clang version 6.0.0 (trunk 308728)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
/media/fbarchard/ssd/build/libyuv/src/third_party/llvm-build/Release+Asserts/bin
This is the first part of the error before core dump. See attached
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
obj/libyuv_msa/row_msa.o.d -DV8_DEPRECATION_WARNINGS -DUSE_OPENSSL_CERTS=1
-DNO_TCMALLOC -DDISABLE_NACL -DSAFE_BROWSING_DB_REMOTE -DCHROMIUM_BUILD
-DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=\"308728-3\"
-D_FILE_OFFSET_BITS=64 -DANDROID -DHAVE_SYS_UIO_H
-DANDROID_NDK_VERSION_ROLL=r12b_1 -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DCOMPONENT_BUILD -D__GNU_SOURCE=1
-D__compiler_offsetof=__builtin_offsetof -Dnan=__builtin_nan
-Dsnprintf=snprintf -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-I../.. -Igen -I../../include -fno-strict-aliasing --param=ssp-buffer-size=4
-fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__=
-D__TIMESTAMP__= -funwind-tables -fPIC -pipe -fcolor-diagnostics
-ffunction-sections -fno-short-enums -fintegrated-as
--target=mips64el-linux-androideabi --target=mips64el-linux-android
-march=mips64el -mcpu=mips64r6 -mmsa -mfp64 -Wall -Werror -Wextra
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing
-Wno-covered-switch-default -Wno-unneeded-internal-declaration
-Wno-inconsistent-missing-override -Wno-undefined-var-template
-Wno-nonportable-include-path -Wno-address-of-packed-member
-Wno-unused-lambda-capture -Wno-user-defined-warnings -Oz -fno-ident
-fdata-sections -ffunction-sections -fomit-frame-pointer -g2
--sysroot=../../third_party/android_tools/ndk/platforms/android-21/arch-mips64
-fvisibility=hidden -Xclang -load -Xclang
../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so
-Xclang -add-plugin -Xclang find-bad-constructs -Xclang
-plugin-arg-find-bad-constructs -Xclang check-auto-raw-pointer -Xclang
-plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene
-Wstring-conversion -Wtautological-overlap-compare -std=gnu++11 -fno-rtti
-isystem../../third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++/libcxx/include
-isystem../../third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++abi/libcxxabi/include
-isystem../../third_party/android_tools/ndk/sources/android/support/include
-fno-exceptions -fvisibility-inlines-hidden -c ../../source/row_msa.cc -o
obj/libyuv_msa/row_msa.o
clang:
/b/build/slave/linux_upload_clang/build/src/third_party/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:614:
void getCopyToPartsVector(llvm::SelectionDAG &, const llvm::SDLoc &,
llvm::SDValue, llvm::SDValue *, unsigned int, llvm::MVT, const llvm::Value *,
bool): Assertion `NumRegs == NumParts && "Part count doesn't match vector
breakdown!"' 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 33621] wrong code at -Os on x86_64-linux-gnu (in 64-bit mode only) with "-mllvm -enable-newgvn
https://bugs.llvm.org/show_bug.cgi?id=33621 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Davide Italiano --- Even reverting the MemorySSA patch, I can't reproduce this on ToT, so this probably was fixed/masked somewhere in the middle. -- 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 32362] LLDB master fails to compile with linker error
https://bugs.llvm.org/show_bug.cgi?id=32362 Vedran Miletic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Vedran Miletic --- $ make VERBOSE=1 lldb (...) [ 56%] Built target lldbTarget make -f tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build.make tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/depend make[3]: Entering directory '/home/vedranm/workspace/llvm/build-master' cd /home/vedranm/workspace/llvm/build-master && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/vedranm/workspace/llvm /home/vedranm/workspace/llvm/tools/lldb/tools/lldb-server /home/ vedranm/workspace/llvm/build-master /home/vedranm/workspace/llvm/build-master/tools/lldb/tools/lldb-server /home/vedranm/workspace/llvm/build-master/tools/lldb/tools/lldb-server/CMakeFiles/l ldb-server.dir/DependInfo.cmake --color= make[3]: Leaving directory '/home/vedranm/workspace/llvm/build-master' make -f tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build.make tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build make[3]: Entering directory '/home/vedranm/workspace/llvm/build-master' [ 56%] Linking CXX executable ../../../../bin/lldb-server cd /home/vedranm/workspace/llvm/build-master/tools/lldb/tools/lldb-server && /usr/bin/cmake -E cmake_link_script CMakeFiles/lldb-server.dir/link.txt --verbose=1 /usr/lib/ccache/c++-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wn o-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -g -Wl,-allow-shlib-undefined -Wl,-rpath-link,/home/vedranm/workspace/llvm/build-master/./lib CMakeFiles/lldb-server.dir/Acceptor.cpp.o CMakeFiles/lldb-server.dir/lldb-gdbserver.cpp.o C MakeFiles/lldb-server.dir/lldb-platform.cpp.o CMakeFiles/lldb-server.dir/lldb-server.cpp.o CMakeFiles/lldb-server.dir/LLDBServerUtilities.cpp.o -o ../../../../bin/lldb-server -Wl,-rpath,"\$ORIGIN/../lib" -lpthread ../../../../lib/liblldbBase.a ../../../../lib/liblldbCore.a ../../../../lib/liblldbHost.a ../../../../lib/liblldbInitialization.a ../../../../lib/liblldbInterpreter. a ../../../../lib/liblldbPluginProcessLinux.a -ledit -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr/lib/x86_64-linux-gnu/libpanel.so -ltinfo /usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so -lpthread -ldl -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr/lib/x86_64-linux-gnu/libpanel.so -ledit -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr /lib/x86_64-linux-gnu/libpanel.so -ltinfo /usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so -lpthread -ldl -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr/lib /x86_64-linux-gnu/libpanel.so -ledit -ltinfo /usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so -lpthread -ldl -ledit -lcurses /usr/lib/x86_64-linux-gnu/libform.s o /usr/lib/x86_64-linux-gnu/libpanel.so -ltinfo /usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so -lpthread -ldl ../../../../lib/liblldbPluginInstructionARM.a .. /../../../lib/liblldbPluginInstructionMIPS.a ../../../../lib/liblldbPluginInstructionMIPS64.a ../../../../lib/libLLVMMC.so.6.0.0svn ../../../../lib/libLLVMMipsCodeGen.so.6.0.0svn ../../../.. /lib/libLLVMMipsAsmPrinter.so.6.0.0svn ../../../../lib/libLLVMMipsAsmParser.so.6.0.0svn ../../../../lib/libLLVMMipsDesc.so.6.0.0svn ../../../../lib/libLLVMMipsInfo.so.6.0.0svn ../../../../li b/libLLVMMipsDisassembler.so.6.0.0svn ../../../../lib/liblldbPluginObjectContainerMachOArchive.a ../../../../lib/liblldbPluginObjectFilePECOFF.a ../../../../lib/liblldbPluginProcessGDBRemote .a ../../../../lib/liblldbPluginPlatformMacOSX.a ../../../../lib/liblldbPluginPlatformPOSIX.a ../../../../lib/liblldbPluginProcessPOSIX.a ../../../../lib/liblldbCore.a ../../../../lib/liblld bHost.a ../../../../lib/liblldbInterpreter.a ../../../../lib/liblldbBreakpoint.a ../../../../lib/liblldbDataFormatters.a ../../../../lib/liblldbExpression.a ../../../../lib/liblldbSymbol.a . ./../../../lib/liblldbTarget.a ../../../../lib/liblldbPluginProcessUtility.a ../../../../lib/liblldbPluginCPlusPlusLanguage.a ../../../../lib/liblldbPluginObjCLanguage.a ../../../../lib/libl ldbPluginObjectFileJIT.a ..
[llvm-bugs] [Bug 34007] New: Regression(r309526): DWARF info may be corrupt; offsets in a range list entry are in different sections
https://bugs.llvm.org/show_bug.cgi?id=34007 Bug ID: 34007 Summary: Regression(r309526): DWARF info may be corrupt; offsets in a range list entry are in different sections Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Created attachment 18880 --> https://bugs.llvm.org/attachment.cgi?id=18880&action=edit test.ii test.ii is cxa_default_handlers.cpp from libc++abi after preprocessing. Compile like so: ../../llvm-build-nolibcxx/bin/clang++ -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -Bthird_party/binutils/Linux_x64/Release/bin -pthread -fcolor-diagnostics -m32 -msse2 -mfpmath=sse -mmmx -momit-leaf-frame-pointer -mstack-alignment=16 -mstackrealign -O0 -fno-omit-frame-pointer -gdwarf-3 -g2 -ggnu-pubnames -gsplit-dwarf -fvisibility=hidden -fPIC -fstrict-aliasing -std=gnu++14 -fvisibility-inlines-hidden -frtti -x c++ -c test.ii -o test.o Then link like so: ../../llvm-build-nolibcxx/bin/clang++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread -Wl,--as-needed -fuse-ld=gold -Bthird_party/binutils/Linux_x64/Release/bin -nodefaultlibs -m32 -Wl,--gdb-index --sysroot=build/linux/debian_jessie_i386-sysroot test.o third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: test.o: DWARF info may be corrupt; offsets in a range list entry are in different sections buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:29: error: undefined reference to '__cxa_get_globals_fast' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:53: error: undefined reference to '__cxa_demangle' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:0: error: undefined reference to 'typeinfo for std::exception' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:63: error: undefined reference to 'abort_message' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:68: error: undefined reference to 'abort_message' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:73: error: undefined reference to 'abort_message' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:77: error: undefined reference to 'abort_message' buildtools/third_party/libc++abi/trunk/src/cxa_default_handlers.cpp:84: error: undefined reference to 'std::terminate()' clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation) The undefined references are fine (an artifact of reducing this to one file), but the "DWARF info may be corrupt" is not good. Download http://commondatastorage.googleapis.com/chrome-linux-sysroot/toolchain/6f7741c4222de05cd5f2fbb9f02d34f76e5a3134/debian_jessie_i386_sysroot.tar.xz and extract it to build/linux/debian_jessie_i386-sysroot to get that sysroot and http://commondatastorage.googleapis.com/chromium-binutils/0cb5726d9701f8be6a81b199899de1de552922f2 and put it at third_party/binutils/Linux_x64/Release/bin to get that gold (it's I think a prebuilt of the latest stable gold, maybe with some cherry-picked patches). -- 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 34008] New: Clang-format BreakConstructorInitializers ignored if BraceWrapping->AfterFunction is true
https://bugs.llvm.org/show_bug.cgi?id=34008
Bug ID: 34008
Summary: Clang-format BreakConstructorInitializers ignored if
BraceWrapping->AfterFunction is true
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: staypriv...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
trunk@309628
With AfterFunction: true
X::Y::Z()
: a(0), b(0), c(0), d(0)
{
}
With After::Function false
X::Y::Z()
: a(0)
, b(0)
, c(0)
, d(0) {
}
Trying to achieve:
X::Y::Z()
: a(0)
, b(0)
, c(0)
, d(0)
{
}
.clang-format:
---
Language:Cpp
# BasedOnStyle: Google
AccessModifierOffset: -1
AlignAfterOpenBracket: Align
AlignConsecutiveAssignments: true
AlignConsecutiveDeclarations: true
AlignEscapedNewlines: Right
AlignOperands: true
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: true
AllowShortFunctionsOnASingleLine: InlineOnly
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: false
BinPackArguments: true
BinPackParameters: true
BraceWrapping:
AfterClass: true
AfterControlStatement: true
AfterEnum: true
AfterFunction: true
AfterNamespace: false
AfterObjCDeclaration: true
AfterStruct: true
AfterUnion: true
BeforeCatch: true
BeforeElse: true
IndentBraces:false
SplitEmptyFunction: true
SplitEmptyRecord: true
SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Custom
BreakBeforeInheritanceComma: true
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: true
BreakConstructorInitializers: BeforeColon
BreakAfterJavaFieldAnnotations: false
BreakStringLiterals: true
ColumnLimit: 140
CommentPragmas: '^ IWYU pragma:'
CompactNamespaces: true
ConstructorInitializerAllOnOneLineOrOnePerLine: true
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 4
Cpp11BracedListStyle: true
DerivePointerAlignment: false
DisableFormat: false
ExperimentalAutoDetectBinPacking: false
FixNamespaceComments: true
ForEachMacros: [ foreach, Q_FOREACH, BOOST_FOREACH ]
IncludeCategories:
- Regex: '^___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34009] New: Clang 5.0 consider template method unevaluated and accepts this code, GCC rejects it
https://bugs.llvm.org/show_bug.cgi?id=34009
Bug ID: 34009
Summary: Clang 5.0 consider template method unevaluated and
accepts this code, GCC rejects it
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: joker@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Clang accepts the following (C++11) code while GCC rejects it (4.9 to 7.0).
Clang seems to consider that the constexpr `IS_N` is enough to make the method
`bar()` unevaluated, while gcc complains. I don't understand what makes clang
happy here?
Changing the define makes both compiler happy, as the constexpr is dependent on
the template args.
#include
#define INDEPENDENT_CONSTEXPR 1
template
struct Bar {
typename std::enable_if::type foo() {
}
};
template
struct Foo {
#if INDEPENDENT_CONSTEXPR
static constexpr bool IS_N = true;
#else
static constexpr bool IS_N = (N == 1);
#endif
// (N == 1);
using myBar = Bar;
void bar() {
myBar b;
b.foo();
}
};
void foobar() {
Foo<0> f0;
Foo<1> f1;
#if !INDEPENDENT_CONSTEXPR
f0.bar();
#endif
// Following should never work
// f1.bar();
}
--
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 33619] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode) with "-mllvm -enable-newgvn
https://bugs.llvm.org/show_bug.cgi?id=33619 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Davide Italiano --- This doesn't reproduce on ToT (or on the original revision). I asked Zhendong and he followed up privately saying he's not able to reproduce either. Feel free to reopen (or open a new bug), should something change. -- 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 31870] test/tools/llvm-symbolizer/print_context.c fails on debian amd64
https://bugs.llvm.org/show_bug.cgi?id=31870 Dylan McKay changed: What|Removed |Added CC||dblai...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dylan McKay --- Fixed by David Blaikie in r309517 Most of the other symbolizer tests had object files checked in rather than generated by the host compiler. David has changed this test to work the same 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 34010] New: libc++ doesn't work with glibc 2.26
https://bugs.llvm.org/show_bug.cgi?id=34010 Bug ID: 34010 Summary: libc++ doesn't work with glibc 2.26 Product: libc++ Version: 5.0 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: b...@linaro.org CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 18882 --> https://bugs.llvm.org/attachment.cgi?id=18882&action=edit Fix libc++ doesn't work with (soon to be released) glibc 2.26 because the (nonstandard) xlocale.h header has been removed from glibc, but is being included by libc++. The patch I'm attaching fixes the issue for glibc 2.26, but should be tested on older glibc versions. -- 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 34011] New: compiler-rt can't be built with glibc 2.26
https://bugs.llvm.org/show_bug.cgi?id=34011 Bug ID: 34011 Summary: compiler-rt can't be built with glibc 2.26 Product: compiler-rt Version: 5.0 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: b...@linaro.org CC: llvm-bugs@lists.llvm.org Created attachment 18883 --> https://bugs.llvm.org/attachment.cgi?id=18883&action=edit Fix glibc 2.26 (soon to be released) drops the incorrectly (non-)namespaced sigaltstack typedef and replaces it with stack_t. compiler-rt currently uses struct sigaltstack, causing the build to fail. Fix is tested with glibc 2.26, should be tested on older glibc versions. -- 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 34012] New: --no-undefined-version fails with version aliases
https://bugs.llvm.org/show_bug.cgi?id=34012
Bug ID: 34012
Summary: --no-undefined-version fails with version aliases
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: smee...@fb.com
CC: compn...@compnerd.org, gri...@accesssoftek.com,
llvm-bugs@lists.llvm.org, rafael.espind...@gmail.com,
r...@google.com
# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
# RUN: echo "V1 { global: f; local: *; };" > %t.script
# RUN: ld.lld -shared --version-script %t.script --no-undefined-version %t.o \
# RUN: -o %t.so
.global _f
_f:
retq
.symver _f, f@V1
The above fails with
error: version script assignment of 'V1' to symbol 'f' failed: symbol not
defined
We attempt to look up f in the symbol table. However, the symbol table actually
contains f@V1, so the lookup fails.
I'm not 100% sure my version script (marking a symbol as global when it already
has a .symver) is valid, but both bfd and gold are happy with it. Additionally,
bfd actually needs the global: f to export the symbol even with the .symver;
gold and lld export it without.
--
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 34010] libc++ doesn't work with glibc 2.26
https://bugs.llvm.org/show_bug.cgi?id=34010 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Marshall Clow (home) --- *** This bug has been marked as a duplicate of bug 33729 *** -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 34010, which changed state. Bug 34010 Summary: libc++ doesn't work with glibc 2.26 https://bugs.llvm.org/show_bug.cgi?id=34010 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 31868] NewGVN needs support for multiple fake expressions for instructions
https://bugs.llvm.org/show_bug.cgi?id=31868 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Davide Italiano --- Fixed now that NewGVN is complete. -- 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 30995] [META][GVN] NewGVN Integration
https://bugs.llvm.org/show_bug.cgi?id=30995 Bug 30995 depends on bug 31868, which changed state. Bug 31868 Summary: NewGVN needs support for multiple fake expressions for instructions https://bugs.llvm.org/show_bug.cgi?id=31868 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 17674] [AArch64] MachineInstr verifier fails due to nested ADJCALLSTACK
https://bugs.llvm.org/show_bug.cgi?id=17674 Eli Friedman changed: What|Removed |Added CC||efrie...@codeaurora.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Eli Friedman --- https://reviews.llvm.org/rL309642 -- 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 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS
https://bugs.llvm.org/show_bug.cgi?id=32146 Bug 32146 depends on bug 17674, which changed state. Bug 17674 Summary: [AArch64] MachineInstr verifier fails due to nested ADJCALLSTACK https://bugs.llvm.org/show_bug.cgi?id=17674 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 34013] New: OpenMP 4.5: Target construct in methods of class fail to map an array tofrom
https://bugs.llvm.org/show_bug.cgi?id=34013
Bug ID: 34013
Summary: OpenMP 4.5: Target construct in methods of class fail
to map an array tofrom
Product: OpenMP
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: serg...@udel.edu
CC: llvm-bugs@lists.llvm.org
Created attachment 18884
--> https://bugs.llvm.org/attachment.cgi?id=18884&action=edit
reproducible of issue
Dear LLVM OpenMP 4.5 support.
I'm trying to use a target construct inside the methods of a class to compute
something in an array. But, it seems that once the target construct finishes
the data of the array is not copied back from to device to the host.
Basically, what I expect after calling the modify method on an object of A is
that the h_array will be full of 1s, but it is not working.
class A {
...
void modify(int* isHost) {
#pragma omp target map(tofrom:this->h_array) map(this->size) map(tofrom:
isHost)
{
*isHost = omp_is_initial_device();
for (int i = 0; i < size; ++i)
h_array[i] = 1;
}
}
};
I'm attaching a reproducible for the error.
# Compile
To compile: clang++ -fopenmp -fopenmp-targets=nvptx64-nvida-cuda repro1.cpp
# MACHINE
I tested this in a 64 bit system.
- clang version 3.8.0 (ibmgithub:/CORAL-LLVM-Compilers/clang.git
6dec6f47d3868e3c8bf6e9e19a217cb2b459d3d8)
(ibmgithub:/CORAL-LLVM-Compilers/llvm.git
b1d578319dbe65eb1e654c6b4e3d05dfcaa087a6)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
- Red Hat Enterprise Linux Server 7.3 - CentOS release 7
- POWER8NVL ppc64le
- NVIDIA Tesla P100 GPU
--
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 34014] New: OpenMP 4.5: Target construct in static method of class fails to map class static variable
https://bugs.llvm.org/show_bug.cgi?id=34014 Bug ID: 34014 Summary: OpenMP 4.5: Target construct in static method of class fails to map class static variable Product: OpenMP Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: serg...@udel.edu CC: llvm-bugs@lists.llvm.org Created attachment 18885 --> https://bugs.llvm.org/attachment.cgi?id=18885&action=edit repro files Dear LLVM OpenMP 4.5 support. I'm trying to use a target construct inside a static method of a class and access a static member of the class inside the target construct. But, I'm getting a compiler error. I'm attaching a reproducible for the error. # Compile To compile: clang++ -fopenmp -fopenmp-targets=nvptx64-nvida-cuda repro2.cpp # MACHINE I tested this in a 64 bit system. - clang version 3.8.0 (ibmgithub:/CORAL-LLVM-Compilers/clang.git 6dec6f47d3868e3c8bf6e9e19a217cb2b459d3d8) (ibmgithub:/CORAL-LLVM-Compilers/llvm.git b1d578319dbe65eb1e654c6b4e3d05dfcaa087a6) Target: powerpc64le-unknown-linux-gnu Thread model: posix - Red Hat Enterprise Linux Server 7.3 - CentOS release 7 - POWER8NVL ppc64le - NVIDIA Tesla P100 GPU -- 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 34015] New: Backport r309495 to 5.0 - Tie source and destination operands for AESMC/AESIMC.
https://bugs.llvm.org/show_bug.cgi?id=34015 Bug ID: 34015 Summary: Backport r309495 to 5.0 - Tie source and destination operands for AESMC/AESIMC. Product: libraries Version: 5.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: florian.h...@arm.com CC: llvm-bugs@lists.llvm.org It would be great if this change could make it in the 5.0 release cycle, as it significantly improves performance of commercial benchmarks using AES instructions on most ARM cores implementing AES instruction fusion. https://reviews.llvm.org/rL309495 -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33970, which changed state. Bug 33970 Summary: build of clang apply replacement is failing with an "invalid conversion" https://bugs.llvm.org/show_bug.cgi?id=33970 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 34016] New: Missing enter before bracket in typedef enum and extern
https://bugs.llvm.org/show_bug.cgi?id=34016
Bug ID: 34016
Summary: Missing enter before bracket in typedef enum and
extern
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: bubyoffic...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Clang-format configuration:
BreakBeforeBraces: Custom
BraceWrapping: { AfterClass: true, AfterControlStatement: true, AfterEnum:
true, AfterFunction: true, AfterNamespace: false, AfterStruct: true,
AfterUnion: true, BeforeCatch: true, BeforeElse: true }
Formatted part of code:
// BEFORE
typedef enum
{
a,
b,
c
} SomeEnum;
extern "C"
{
#include
}
// AFTER
typedef enum {
a,
b,
c
} SomeEnum;
extern "C" {
#include
}
Is there a way, to move the bracket to next line? Is this a bug? I tried almost
all values of BreakBeforeBraces property, and I couldn't get desired effect.
--
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
