[llvm-bugs] [Bug 28291] LLVM trunk crash with knl target (Assertion `C1->getType() == C2->getType())
https://llvm.org/bugs/show_bug.cgi?id=28291 igorb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from igorb --- work with clang version 4.0.0 (trunk 278653) -- 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 28979] New: [fast-math] support for math flags 'nsz', 'arcp', 'fast' in opt and TargetOptions
https://llvm.org/bugs/show_bug.cgi?id=28979 Bug ID: 28979 Summary: [fast-math] support for math flags 'nsz', 'arcp', 'fast' in opt and TargetOptions Product: libraries Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: l...@henning-thielemann.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified It seems that opt -enable-no-infs-fp-math adds ninf globally opt -enable-no-nans-fp-math adds nnan globally but I do not see counterparts for the flags 'nsz', 'arcp' and 'fast'. I also do not see corresponding flags in TargetOptions. Am I missing something? Is there another way to apply fast-math flags to whole functions or modules? Or is it discouraged for some reason, anyway? -- 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 28980] New: memcpy without llvm.mem.parallel_loop_access metadata in loop annotated with #pragma clang loop vectorize(assume_safety)
https://llvm.org/bugs/show_bug.cgi?id=28980
Bug ID: 28980
Summary: memcpy without llvm.mem.parallel_loop_access metadata
in loop annotated with #pragma clang loop
vectorize(assume_safety)
Product: clang
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16949
--> https://llvm.org/bugs/attachment.cgi?id=16949&action=edit
Example .cpp and output of clang for that .cpp where memcpy is missing the
mem_par metadata
Clang doesn't attach a llvm.mem.parallel_loop_access metadata for memcpy
instructions in a loop that is annotated with
#pragma clang loop vectorize(assume_safety):
Example1:
#pragma clang loop vectorize(assume_safety)
for (long i = 0; i < size; i+=2) {
memcpy(&(out[i]), &(out[i+size]), 2);
}
Example2: Here the struct copies result in a memcpy:
void test(Complex *out, long size)
{
long m = size / 2;
#pragma clang loop vectorize(assume_safety)
for (long offset = 0; offset < m; ++offset) {
Complex t0 = out[offset];
Complex t1 = out[offset+m];
out[offset] = t0 + t1;
out[offset+m] = t0 - t1;
}
}
.c and .ll created by clang attached.
Generated the .ll like so:
clang++ -S -emit-llvm -mllvm -disable-llvm-optzns [-g -m64 -static -mfpmath=sse
-march=core-avx2]
--
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 28981] New: Missed forced vectorization due to llvm.mem.parallel_loop_access getting lost
https://llvm.org/bugs/show_bug.cgi?id=28981
Bug ID: 28981
Summary: Missed forced vectorization due to
llvm.mem.parallel_loop_access getting lost
Product: tools
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16953
--> https://llvm.org/bugs/attachment.cgi?id=16953&action=edit
Example loop with #pragma clang loop vectorize(assume_safety)
The following loop does not get vectorized because we lose some of the
information that is implied by "#pragma clang loop vectorize(assume_safety)":
void test(Complex *out, long size)
{
long m = size / 2;
#pragma clang loop vectorize(assume_safety)
for (long offset = 0; offset < m; ++offset) {
Complex t0 = out[offset];
Complex t1 = out[offset+m];
out[offset] = t0 + t1;
out[offset+m] = t0 - t1;
}
}
clang++ -S force-vect-test1.cpp -g -m64 -Ofast -funroll-loops -static
-mfpmath=sse -march=core-avx2 -Rpass-analysis=loop-vectorize
force-vect-test1.cpp:29:5: remark: loop not vectorized: cannot check memory
dependencies at runtime [-Rpass-analysis]
for (long offset = 0; offset < m; ++offset) {
^
force-vect-test1.cpp:29:5: warning: loop not vectorized: failed explicitly
specified loop vectorization [-Wpass-failed]
By the time this loop reaches the vectorizer, some of the memory operations in
the loop don't have the llvm.mem.parallel_loop_access metadata, because:
1) clang does not annotate the memcpy that it creates in the loop with the
llvm.mem.parallel_loop_access metadata (this is PR28980)
2) Even if we annotate the memcpy manually, InstCombine later replaces it with
a ld/st and does not copy over the llvm.mem.parallel_loop_access metadata (this
is D23499)
3) later SROA does not preserve the llvm.mem.parallel_loop_access metadata
during its transformations (will upload a proposed patch shortly)
--
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 28974] [AVX512]: fatal error: error in backend: Cannot select: 0x7fbc0022a050
https://llvm.org/bugs/show_bug.cgi?id=28974 Wenzel Jakob changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Wenzel Jakob --- I think my Clang trunk must have been a couple of days old. After updating to the latest revision, I can't reproduce this bug anymore (neither with Debug nor with a Release build). Sorry about that. -- 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 26645] [LIR] Non-temporal aspect dropped via conversion to memset in some cases
https://llvm.org/bugs/show_bug.cgi?id=26645 Haicheng Wu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Haicheng Wu --- I believe it is 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 28600] [meta] 3.9.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=28600 Bug 28600 depends on bug 28104, which changed state. Bug 28104 Summary: crash on -Os and above in 32-bit mode on x86_64-linux-gnu (Incorrect LI specified for this loop) https://llvm.org/bugs/show_bug.cgi?id=28104 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 28104] crash on -Os and above in 32-bit mode on x86_64-linux-gnu (Incorrect LI specified for this loop)
https://llvm.org/bugs/show_bug.cgi?id=28104 Haicheng Wu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Haicheng Wu --- I committed the patch in r278575. -- 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 28983] New: Regression(278661:278653): casting assertion in InstCombine on SSE2 QCMS code
https://llvm.org/bugs/show_bug.cgi?id=28983 Bug ID: 28983 Summary: Regression(278661:278653): casting assertion in InstCombine on SSE2 QCMS code Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Appears here in Chromium: https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinux/builds/6037/steps/compile/logs/stdio LLVM changes inside the blamelist: $ git log --format=oneline 24088baa9daf1df2482084741d28729d2278c385..47a3de7f4db76bd34b6a9b1202841d4b85294ca5 47a3de7f4db76bd34b6a9b1202841d4b85294ca5 MachineLoop: add methods findLoopControlBlock and findLoopPreheader 7bc6001b578c682790e28bd8031d9f3641f10603 [SimplifyCFG] Rewrite SinkThenElseCodeToEnd 91c19fbe6c94facc80531437d32f8015c16c3752 [Thumb] Validate branch target for CBZ/CBNZ instructions. bd7c3fb3bf8a73e669d80ab5c30d53e7de573a2e [LSR] Don't try and create post-inc expressions on non-rotated loops I suspect the SimplifyCFG and LSR changes, since the other changes are in CodeGen, not IR. -- 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 28984] New: SCEV not sufficiently invalidated - Results in non-dominating expressions to be inserted
https://llvm.org/bugs/show_bug.cgi?id=28984
Bug ID: 28984
Summary: SCEV not sufficiently invalidated - Results in
non-dominating expressions to be inserted
Product: Polly
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: tob...@grosser.es
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
opt -polly-process-unprofitable -polly-remarks-minimal -S -polly-codegen
-polly-invariant-load-hoisting=false
test/Isl/CodeGen/hoisted_load_escapes_through_phi.ll
fails with r78673:
%tmp1 = load i32, i32* @cont_STACKPOINTER, align 4
%0 = sext i32 %tmp1 to i64
Polly generated function could not be verified. Add -polly-codegen-verify=false
to disable this assertion.
The test case contains two scops in a row, where the first scop is code
generated "before" the second scop. Unfortunately the second scop references
the first scop in some of the SCEV expressions used, which results in parameter
values of the second scop referencing an instruction ('tmp1') which is not any
more dominating the second scop.
We probably need to run SE.forgetValue() for all instruction in the original
scop region. However, this might conflict with the caching of SCEV instructions
in ScopDetection.
--
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 28985] New: Invariant load hoisting causes LNT miscompiles
https://llvm.org/bugs/show_bug.cgi?id=28985 Bug ID: 28985 Summary: Invariant load hoisting causes LNT miscompiles Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified With 278673 -polly -polly-process-unprofitable LNT shows the following miscompile: FAIL: lencod.execution_time This miscompile disappears when disabling invariant load hoisting. It is not yet confirmed that this is due to invariant load hoisting. More investigation is needed to confirm 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 28986] New: type-id/expression in cstyle-cast are disambiguated incorrectly
https://llvm.org/bugs/show_bug.cgi?id=28986
Bug ID: 28986
Summary: type-id/expression in cstyle-cast are disambiguated
incorrectly
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: vanya...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
clang shows syntax error on this code. Looks like it disambiguates the
expression "(mytype())(args...)" as cstyle-cast although "(args...)" is not a
valid cast-expression.
struct mytype
{
template
void operator()(T&& ...) const
{}
};
template
void f(T&& ...args)
{
(mytype())(args...); // error: expected binary operator before ')' token
}
int main()
{
f(1, 2, 3);
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28987] New: Regression in removing pointer range loops initializing dead variables.
https://llvm.org/bugs/show_bug.cgi?id=28987
Bug ID: 28987
Summary: Regression in removing pointer range loops
initializing dead variables.
Product: new-bugs
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: edy.b...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following function is optimized out in clang 3.8, but not 3.9:
void test() {
double a[4];
for(double *p = a, *end = a + 4; p < end; p++)
*p = 0.0;
}
The optimized IR on 3.9 is more or less:
define void @test() {
entry-block:
%a = alloca [4 x double], align 8
%a6 = ptrtoint [4 x double]* %a to i64
%0 = bitcast [4 x double]* %a to i8*
call void @llvm.lifetime.start(i64 32, i8* %0)
%scevgep = getelementptr [4 x double], [4 x double]* %a, i64 1, i64 0
%scevgep1 = ptrtoint double* %scevgep to i64
%scevgep2 = getelementptr [4 x double], [4 x double]* %a, i64 0, i64 1
%scevgep23 = ptrtoint double* %scevgep2 to i64
%1 = icmp ugt i64 %scevgep1, %scevgep23
%umax = select i1 %1, i64 %scevgep1, i64 %scevgep23
%umax45 = inttoptr i64 %umax to i8*
%2 = xor i64 %a6, -1
%uglygep = getelementptr i8, i8* %umax45, i64 %2
%uglygep7 = ptrtoint i8* %uglygep to i64
%3 = add i64 %uglygep7, 8
%4 = and i64 %3, -8
call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 %4, i32 8, i1 false)
call void @llvm.lifetime.end(i64 32, i8* %0)
ret void
}
If the llvm.lifetime.{start,end} calls are removed, running opt again will
reduce this to just "ret void".
Any other uses of %a will also prevent the memset and everything before it to
be removed, *even* if the entire array is statically overwritten.
--
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 28506] : C++11 templates disabled (?) on sunos
https://llvm.org/bugs/show_bug.cgi?id=28506 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED CC||e...@efcs.ca Resolution|--- |FIXED --- Comment #5 from Eric Fiselier --- r278716. -- 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 28988] New: r278659 problem
https://llvm.org/bugs/show_bug.cgi?id=28988 Bug ID: 28988 Summary: r278659 problem Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16957 --> https://llvm.org/bugs/attachment.cgi?id=16957&action=edit Reproducer The new assert/check added in r278659 triggers when building a normal(?) c file from compiler-rt/sanitizer. I attach a reduced example: > llc -filetype=obj err_278659.ll LLVM ERROR: out of range pc-relative fixup value -- 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 28989] New: lldb not sending SIGINT to inferior process
https://llvm.org/bugs/show_bug.cgi?id=28989 Bug ID: 28989 Summary: lldb not sending SIGINT to inferior process Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: pen...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16958 --> https://llvm.org/bugs/attachment.cgi?id=16958&action=edit Source file main.c used to reproduce issue When lldb connects to a previously launchd process via pid, issuing ^C (Ctrl-C) in the tty of the inferior process correctly sends SIGINT to the inferior process. At this point, commands to `process handle SIGINT ...` can be used to route the signal as the user wants. However, if the inferior process is launched by lldb itself, either via `lldb ./some_bin` at the command line, or via `target create ...` from within lldb; Ctrl-C is only received by lldb, and cannot be forwarded to the inferior process as a SIGINT. Note that sending a SIGINT to the debugged process with kill(1) or kill(2) will work, but is only a workaround. = Produce executable from attached source = $ clang -g -o main main.c = Attach to pid = # launch ./main in separate tty (lldb) pr at -p N (lldb) pr ha SIGINT -p true -s false (lldb) c # issue ^C in tty running ./main # ./main process exits via custom handler as intended = Launch from inside lldb = $ lldb (lldb) ta cr ./main (lldb) br s -n main (lldb) r Process N stopped ... stop reason = signal SIGSTOP [...] (lldb) pr ha SIGINT -p true -s false (lldb) c ^C Process N stopped ... stop reason = signal SIGSTOP [...] # ^C never results in a SIGINT to inferior process -- 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 28990] New: Incorrect sample profile when braces omitted
https://llvm.org/bugs/show_bug.cgi?id=28990
Bug ID: 28990
Summary: Incorrect sample profile when braces omitted
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: dcalla...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16959
--> https://llvm.org/bugs/attachment.cgi?id=16959&action=edit
script to demonstrate
Attached are two source variables, bug1.cc and bug2.cc which differ only in the
placement of braces around a then-statement. When these braces are omitted, a
profile-based sample is incorrect while it is correct when they are present.
Reproduction steps are in bug1.sh
create_llvm_prof is available at https://github.com/google/autofdo
The incorrect sample derived from bug1.cc (from llvm-profdata show) is:
Function: _Z8clampSumPdidd: 100803968, 0, 13 sampled lines
Samples collected in the function's body {
0: 0
1: 0
2.1: 908152
2.2: 908138
3: 908139
4: 0
5: 908146
6: 908142
7: 908150
9: 908149
10: 908146
11: 908138
13: 4
}
while the correct sample derived from bug2.cc is
Function: _Z8clampSumPdidd: 101434538, 1, 14 sampled lines
Samples collected in the function's body {
0: 1
1: 1
2.1: 913831
2.2: 913817
3: 913818
4: 0
5: 913830
6: 913826
7: 0
8: 913834
9: 913831
10: 913827
11: 913821
13: 1
}
where the key differences is the value for relative line 7, it should be 0.
--
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 28991] New: Incorrect sample profiles at O3
https://llvm.org/bugs/show_bug.cgi?id=28991
Bug ID: 28991
Summary: Incorrect sample profiles at O3
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dcalla...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16963
--> https://llvm.org/bugs/attachment.cgi?id=16963&action=edit
Tar file of script and input files
bug2.sh generates the reproduction where we compile a training program either
-00 or -03.
The -O0 training yield this sample
Function: _Z8clampSumPdidd: 105434939, 1, 14 sampled lines
Samples collected in the function's body {
0: 1
1: 1
2.1: 949899
2.2: 949797
3: 949833
4: 0
5: 949926
6: 949896
7: 0
8: 949929
9: 949904
11: 949889
12: 949809
14: 4
}
while the -O3 training yields this sample
Function: _Z8clampSumPdidd: 76108151, 2, 9 sampled lines
Samples collected in the function's body {
0: 2
2.1: 1435907
3: 1436091
6: 1436048
7: 1436032
9: 2
11: 1435984
12: 1435974
14: 2
}
Note the differences in values for relative statements 7 and 9.
The corresponding branch_weights are
!74 = !{!"branch_weights", i32 1, i32 949905}
and
!74 = !{!"branch_weights", i32 1436033, i32 3}
The -O3 sample inverts the relative weights relative to the (correct) -O0
sample.
The attached tar file has bug2.sh, bug.cc and main.cc and a snapshot of bug2.sh
output.
--
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 28992] New: amdgpu.private-memory.ll test failing on windows
https://llvm.org/bugs/show_bug.cgi?id=28992 Bug ID: 28992 Summary: amdgpu.private-memory.ll test failing on windows Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org, r...@google.com Classification: Unclassified For example: http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9701 Last good: r278587 First bad: r278590 -- 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 28992] amdgpu.private-memory.ll test failing on windows
https://llvm.org/bugs/show_bug.cgi?id=28992 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans Wennborg --- Yup, test passes for me locally. -- 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 28978] Assertion in setImplicitMoveConstructorIsDeleted() fails
https://llvm.org/bugs/show_bug.cgi?id=28978 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Smith --- Fixed in r278763. -- 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 28993] New: Unexpected #include_next behavior on clang 3.8
https://llvm.org/bugs/show_bug.cgi?id=28993 Bug ID: 28993 Summary: Unexpected #include_next behavior on clang 3.8 Product: clang Version: 3.8 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: pump...@me.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16964 --> https://llvm.org/bugs/attachment.cgi?id=16964&action=edit Small reproduction As of 3.8, libc++ now bundles a small stdlib.h that does #include_next to get the real stdlib.h. My issues arise in the following scenario: - I'm building libc++abi 3.8.0 - I'm building it on a host with llvm/clang/libc++/libc++abi all at 3.8.0 - To build, I need to provide libc++abi's build process with the libc++ source code - My libc++abi build fails complaining about a bunch of missing stdlib.h identifiers - Upon deeper investigation, it turns out that the proper glibc stdlib.h never gets #included into the compilation >From what I can gather from -v, my search path looks something like: 1. Headers from libc++ source tree I pass to libc++abi build 2. System libc++ headers 3. A couple more unrelated things 4. glibc headers (which I've checked indeed do contain a valid stdlib.h) Judging by -E and -H, clang++ seems to decide that it's included enough after step #2 above, and never makes its way down to #4 to get my system stdlib.h. I'm attaching a reduced test case that demonstrates my confusion. The tarball contains test.sh and test2.sh that demonstrate the problem with both -I and -isystem on a brand new vanilla Ubuntu 14.04 instance that I just installed clang 3.8 onto as well as standard development tools to get system headers. Not sure if I'm doing something wrong, but this behavior doesn't fit what I'd expect of #include_next. -- 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 28994] New: Clang spams a -Wunreachable-code warning for some Firefox code that it didn't warn about in 3.8
https://llvm.org/bugs/show_bug.cgi?id=28994
Bug ID: 28994
Summary: Clang spams a -Wunreachable-code warning for some
Firefox code that it didn't warn about in 3.8
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: dholb...@mozilla.com
CC: cpeter...@mozilla.com, dblai...@gmail.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
I'm spinning this off to cover the behavior-difference between clang 3.8 vs 3.9
discussed in bug 28918.
In the Firefox build process, we have some autogenerated C++ code[1] that looks
like this:
> JS::Rooted rval(cx, JS::UndefinedValue());
> [SNIP]
>if ((false) && !CallerSubsumes(rval)) {
> ThrowErrorMessage(...etc...)
In clang 3.8, this code compiles just fine.
In clang 3.9, this code triggers an unreachable code warning for the
ThrowErrorMessage call in clang 3.9. It should not, because the "false" in the
if-condition is wrapped in parens, which is supposed to be a hint that
Wunreachable-code warnings should be suppressed.
My first attempt at minimizing a C++ testcase from this code produced something
that caused the same issue in older clang revisions (and bug 28918 is filed on
that long-standing bug) So, I'm still not exactly sure what exact conditions
are involved in the 3.8-3.9 behavior-change here.
HOWEVER, I did try bisecting the clang source to find the first SVN revision
that exhibits the problem. That first revision is r273312:
http://llvm.org/viewvc/llvm-project?view=revision&revision=273312
If I check out & build the previous revision of clang (273311), I do not
encounter this error when building Firefox. But with 273312, I do encounter
this error.
[1] The autogenerated C++ code in question here is
$OBJ/dom/bindings/TestCodeGenBinding.cpp ($OBJ is the object directory, i.e.
where files generated by our build process end up)
--
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 28993] Unexpected #include_next behavior on clang 3.8
https://llvm.org/bugs/show_bug.cgi?id=28993 Dan Peebles changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dan Peebles --- Turns out it wasn't quite PEBKAC, but the description/repro in here is utterly inaccurate and misleading. I'll investigate further and possibly file another bug if it's indeed a clang problem. -- 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
