[llvm-bugs] [Bug 26630] New: [Hexagon] J2_jump instruction with a global address fails with: Assertion `isMBB() && "Wrong MachineOperand accessor"'
https://llvm.org/bugs/show_bug.cgi?id=26630 Bug ID: 26630 Summary: [Hexagon] J2_jump instruction with a global address fails with: Assertion `isMBB() && "Wrong MachineOperand accessor"' Product: tools Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: r...@sics.se CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15909 --> https://llvm.org/bugs/attachment.cgi?id=15909&action=edit ZIP file with a test case to reproduce the failure and a tentative patch llc fails when facing J2_jump instructions that do not refer to a basic block but to a global address, such as: J2_jump This yields to a failed assertion of the type `isMBB() && "Wrong MachineOperand accessor"' triggered from HexagonInstrInfo.cpp and HexagonNewValueJump.cpp. The failure can be reproduced by running llc on the attached LLVM IR function: $ llc bugpoint-reduced-simplified.ll -march=hexagon -mcpu=hexagonv4 I also attach a small patch that fixes the issue (although it might not do it in the best 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 26631] New: CMake atomic check fails, missing include
https://llvm.org/bugs/show_bug.cgi?id=26631
Bug ID: 26631
Summary: CMake atomic check fails, missing include
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: rianqu...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
I am working with a GCC cross compiler (x86_64-elf), and CMake fails the atomic
check because it cannot find the includes for libc++ (as they have not been
installed into the sysroot yet chicken / egg problem).
"fatal error: cstdint: No such file or directory"
If you look at the code that it is trying to compile, you can see that it uses
these includes:
#include
#include
std::atomic x;
std::atomic y;
int main() {
return x + y;
}
The problem is, the GCC compiler was never given a "-I" for the include folder
that has these. To fix this issue, I have temporarily added the -I to point to
the libcxx repo that I am building with, and it works fine. Once it's done
compiling libcxx, it installs the all of the headers as expected into the
sysroot.
Seems to me... the CMake script should be patched to add it's own include
folder so that it can find the headers it's attempting to use.
--
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 26632] New: Breakpoint opcode triggering SIGBUS on Nexus 6
https://llvm.org/bugs/show_bug.cgi?id=26632
Bug ID: 26632
Summary: Breakpoint opcode triggering SIGBUS on Nexus 6
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: e...@codeplay.com
CC: llvm-bugs@lists.llvm.org, tbergham...@google.com
Classification: Unclassified
Created attachment 15910
--> https://llvm.org/bugs/attachment.cgi?id=15910&action=edit
Source and arm binaries
r260367(http://reviews.llvm.org/D16853) which changed the arm breakpoint
opcodes introduced a bug on Nexus 6 Armv7.
Whenever a breakpoint is hit it triggers a SIGBUS, seen when compiling with
both thumb and 32 bit.
Reverting the commit removes this problem. Note, need to rebuild lldb-server.
Contrived example attached, building source file fact.c using NDK r10e with the
following command lines.
~/Google/arm32_android-toolchain/bin/arm-linux-androideabi-gcc-4.9 fact.c -O0
-marm -fPIE -pie -o fact_32bit.out
~/Google/arm32_android-toolchain/bin/arm-linux-androideabi-gcc-4.9 fact.c -O0
-mthumb -fPIE -pie -o fact_thumb.out
On device
./lldb-server g 127.0.0.1:1234 fact_thumb.out
On host
(lldb) target create ~/Desktop/Scratch/android/fact_thumb.out
Current executable set to '~/Desktop/Scratch/android/fact_thumb.out' (arm).
(lldb) gdb-remote localhost:1234
Process 5109 stopped
* thread #1: tid = 5109, 0xb6f6af88, name = 'fact_thumb.out', stop reason =
signal SIGSTOP
frame #0: 0xb6f6af88
-> 0xb6f6af88: movr0, sp
0xb6f6af8c: blx0xb6f71304
0xb6f6af90: movpc, r0
0xb6f6af94: addlt r11, r4, r0, lsl r5
(lldb) b main
Breakpoint 1: where = fact_thumb.out`main, address = 0xb6fb3370
(lldb) c
Process 5109 resuming
Process 5109 stopped
* thread #1: tid = 5109, 0xb6fb32a0 fact_thumb.out`_start, name =
'fact_thumb.out', stop reason = signal SIGBUS
frame #0: 0xb6fb32a0 fact_thumb.out`_start
fact_thumb.out`_start:
-> 0xb6fb32a0 <+0>: ldrr12, [pc, #0x5c]
0xb6fb32a4 <+4>: push {r11, lr}
0xb6fb32a8 <+8>: ldrr2, [pc, #0x58]
0xb6fb32ac <+12>: addr11, sp, #4
--
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 22303] lld gets confused with STB_GNU_UNIQUE (gcc produced file)
https://llvm.org/bugs/show_bug.cgi?id=22303 Rafael Ávila de Espíndola 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 26575] Assertion: "Address displacement operand is always an immediate or a global"
https://llvm.org/bugs/show_bug.cgi?id=26575 Andrey Turetskiy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrey Turetskiy --- Fixed in r260959. -- 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 26633] New: clang clang::Sema::BuildCXXDefaultArgExpr asserts "isa<> used on a null pointer"
https://llvm.org/bugs/show_bug.cgi?id=26633 Bug ID: 26633 Summary: clang clang::Sema::BuildCXXDefaultArgExpr asserts "isa<> used on a null pointer" Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: yaron.ke...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15911 --> https://llvm.org/bugs/attachment.cgi?id=15911&action=edit example source code clang -fsyntax-only on the atatched file results in Assertion failed: Val && "isa<> used on a null pointer" from clang::Sema::BuildCXXDefaultArgExpr(class clang::SourceLocation,class clang::FunctionDecl *,class clang::ParmVarDecl *). Tested on Windows and Linux x64, clang version 3.9.0 (trunk 260888). -- 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 26631] CMake atomic check fails, missing include
https://llvm.org/bugs/show_bug.cgi?id=26631 Vasileios Kalintiris changed: What|Removed |Added Status|NEW |RESOLVED CC||Vasileios.Kalintiris@imgtec ||.com Resolution|--- |DUPLICATE --- Comment #1 from Vasileios Kalintiris --- *** This bug has been marked as a duplicate of bug 26622 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 26369, which changed state. Bug 26369 Summary: Link with libatomic for targets that don't support atomic ops for all required sizes natively. https://llvm.org/bugs/show_bug.cgi?id=26369 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 26369] Link with libatomic for targets that don't support atomic ops for all required sizes natively.
https://llvm.org/bugs/show_bug.cgi?id=26369 Vasileios Kalintiris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vasileios Kalintiris --- Fixed in r260961. -- 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 26635] New: gcc produces one .gcc_except_table per comdat, we produce only one
https://llvm.org/bugs/show_bug.cgi?id=26635
Bug ID: 26635
Summary: gcc produces one .gcc_except_table per comdat, we
produce only one
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: rafael.espind...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Given
void g();
template void f() {
try {
g();
} catch (int x) {
}
}
template void f();
we produce
.section.gcc_except_table,"a",@progbits
gcc produces
.section.gcc_except_table._Z1fIiEvv,"aG",@progbits,_Z1fIiEvv,comdat
--
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 26636] New: [SimplifyCFG] branch weights are not preserved when forming select
https://llvm.org/bugs/show_bug.cgi?id=26636
Bug ID: 26636
Summary: [SimplifyCFG] branch weights are not preserved when
forming select
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The conditional branch has profile weight metadata:
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
define i32 @foo(i32 %x) #0 {
entry:
%cmp = icmp sgt i32 %x, 4
br i1 %cmp, label %if.then, label %if.end, !prof !0
if.then:
%add = add nsw i32 %x, 7
br label %return
if.end:
%mul = mul nsw i32 %x, 17
br label %return
return:
%retval.0 = phi i32 [ %add, %if.then ], [ %mul, %if.end ]
ret i32 %retval.0
}
!0 = !{!"branch_weights", i32 676, i32 207}
---
But after -simplifycfg, the metadata is gone:
$ ./opt -simplifycfg selbrweight.ll -S
; ModuleID = 'selbrweight.ll'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
define i32 @foo(i32 %x) {
entry:
%cmp = icmp sgt i32 %x, 4
%add = add nsw i32 %x, 7
%mul = mul nsw i32 %x, 17
%retval.0 = select i1 %cmp, i32 %add, i32 %mul
ret i32 %retval.0
}
---
I don't know if weight metadata can currently be applied to selects, but the
select instruction should propagate the weight info that was on the branch.
This was noted by Benjamin Kramer in:
http://reviews.llvm.org/D16836
--
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 26393] -DLLVM_LINK_LLVM_DYLIB:BOOL=ON produces many llvm test suite regressions
https://llvm.org/bugs/show_bug.cgi?id=26393 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #99 from Jack Howarth --- Fixed with the commit of http://llvm.org/viewvc/llvm-project?view=revision&revision=260641 and back port of http://llvm.org/viewvc/llvm-project?view=revision&revision=260693 to 3.8 branch -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 26393, which changed state. Bug 26393 Summary: -DLLVM_LINK_LLVM_DYLIB:BOOL=ON produces many llvm test suite regressions https://llvm.org/bugs/show_bug.cgi?id=26393 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 26484] llvm fails to build when -DLLVM_ENABLE_PIC=OFF
https://llvm.org/bugs/show_bug.cgi?id=26484 Igor Sugak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |su...@fb.com -- 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 26637] New: coff: Add a lld-link driver flag that mirrors the LIB env var
https://llvm.org/bugs/show_bug.cgi?id=26637 Bug ID: 26637 Summary: coff: Add a lld-link driver flag that mirrors the LIB env var Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Like link.exe, lld-link supports setting a LIB env var to a ;-separated list of directories that it's going to search for libraries, to be used e.g. like so: LIB=c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\VC\lib\amd64;c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\win_sdk\Lib\10.0.10586.0\um\x64;c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\win_sdk\Lib\10.0.10586.0\ucrt\x64;c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\VC\atlmfc\lib\amd64 It'd be good if the same feature was also exposed as a regular flag, since not having to set env vars can keep builds simpler. i.e. something like link-lld -lsystem\c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\VC\lib\amd64 -lsystem=c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\win_sdk\Lib\10.0.10586.0\um\x64 -lsystem=c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\win_sdk\Lib\10.0.10586.0\ucrt\x64 -lsystem=c:\src\depot_tools\win_toolchain\vs2013_files\4087e065abebdca6dbd0caca2910c6718d2ec67f\win_sdk\bin\..\..\VC\atlmfc\lib\amd64 -- 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 26638] New: RLEV does not optimize loop
https://llvm.org/bugs/show_bug.cgi?id=26638
Bug ID: 26638
Summary: RLEV does not optimize loop
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: san...@playingwithpointers.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I'd expect -indvars to RLEV away `%count.0.lcssa` in the loop below:
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
define i32 @count_odds(i32 %lim) {
entry:
%cmp8 = icmp sgt i32 %lim, 0
br i1 %cmp8, label %for.body, label %for.cond.cleanup
for.cond.cleanup: ; preds = %for.body, %entry
%count.0.lcssa = phi i32 [ 0, %entry ], [ %count.0.inc, %for.body ]
ret i32 %count.0.lcssa
for.body: ; preds = %entry, %for.body
%i.010 = phi i32 [ %inc2, %for.body ], [ 0, %entry ]
%count.09 = phi i32 [ %count.0.inc, %for.body ], [ 0, %entry ]
%and = and i32 %i.010, 1
%count.0.inc = add i32 %and, %count.09
%inc2 = add i32 %i.010, 1
%exitcond = icmp eq i32 %inc2, %lim
br i1 %exitcond, label %for.cond.cleanup, label %for.body
}
In C, this roughly corresponds to
int count_odds(int lim) {
int count = 0;
for (int i = 0; i < lim; i++)
if ((i & 1) == 1)
count++;
return count;
}
(except that I've removed the nsw and nuws)
--
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 26639] New: ControlFlowIntegrity: ban address-taken mmap, mprotect, etc
https://llvm.org/bugs/show_bug.cgi?id=26639 Bug ID: 26639 Summary: ControlFlowIntegrity: ban address-taken mmap, mprotect, etc Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: pe...@pcc.me.uk Reporter: k...@google.com CC: eugeni.stepa...@gmail.com, k...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified In most cases ControlFlowIntegrity will protect from indirectly calling mmap/mprotect when it is undesired, however if mmap/mprotect is address-taken in the application, the protection becomes weaker. Consider this code: int (*F)(void *, size_t, int); ... int some_user_function(void *, size_t, int); ... F f = &some_user_function; ... f(); ... // unrelated code ... = &mprotect; Here, some_user_function and mprotect will be in the same function signature bucket for CFI and thus the call to f() will allow mprotect. For stronger security we probably want to disallow indirect calls to scary functions like mprotect completely. The simplest way is to implement yet another blacklist: any function in it will cause a compiler warning/error if address-taken. We can also introduce a function attribute that leads to a warning if the function is address-taken. (This is a no-rush feature request) -- 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 26640] New: Unitialized variable usage not checked in some cases
https://llvm.org/bugs/show_bug.cgi?id=26640
Bug ID: 26640
Summary: Unitialized variable usage not checked in some cases
Product: clang
Version: 3.8
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: bdrew...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
cat > test.c << EOF
#include
int main() {
char *p;
int maybe_set_p = 0, flag = 1;
if (maybe_set_p)
p = (char*)malloc(1);
if (flag && p)
;
return 0;
}
EOF
clang38 -Wall -o test test.c
No warning is given about the uninitialized use of p in 'if (flag && p)'.
Changing the 'if (maybe_set_p)' to 'if (0)' shows the warning:
example.c:10:15: warning: variable 'p' is uninitialized when used here
[-Wuninitialized]
if (flag && p)
^
example.c:4:10: note: initialize the variable 'p' to silence this warning
char *p;
^
= NULL
2 warnings generated.
--
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 26640] Unitialized variable usage not checked in some cases
https://llvm.org/bugs/show_bug.cgi?id=26640 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |WONTFIX --- Comment #1 from Richard Smith --- The general problem of determining whether a variable is used uninitialized is not computable, so it is fundamental that we will have false negatives in some cases. Also, as a part of -Wall, this warning cannot be too computationally expensive, and there are limits to the amount of complexity we will allow to detect this, and we do not want the warning under -Wall to have false positives. Our current choice is to diagnose the following under -Wall: -Wuninitialized: diagnose when a use of a variable will *always* read an uninitialized value (that is, when there is no control flow path leading to that point that initializes the variable) -Wsometimes-uninitialized: diagnose when a branching construct is written in the source code, and one of its choices creates the situation that -Wuninitialized diagnoses Note that neither of these checks has any false positives (under the assumption that the user didn't write any branching constructs that always actually branch the same way). If you want more protection against uninitialized uses, we offer one other flag (not under -Wall): -Wconditional-uninitialized: diagnose when a use of a variable could *ever* read an uninitialized value (that is, when there exists a control flow path -- although perhaps one that is dynamically impossible -- leading to the use that does not initialize the variable) Note that this warning flag has no false negatives (at least, for the kinds of variables that it checks, and under the assumption that if the address of the variable escapes the analysis, the variable becomes initialized). If you want more precise, value- and control-flow-dependent analysis, that can detect bugs such as yours by reasoning about the value of the 'flag' variable, you will need a more sophisticated static analyser than the one that powers this warning. You could try using the Clang Static Analyser -- it should catch this 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 26641] New: Spell checking makes diagnostic worse when forgetting template parameters on a template
https://llvm.org/bugs/show_bug.cgi?id=26641
Bug ID: 26641
Summary: Spell checking makes diagnostic worse when forgetting
template parameters on a template
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
This is is a good experience:
$ cat test.cc
#include
void f() {
std::vector v;
}
$ clang -c test.cc
test.cc:4:8: error: use of class template 'std::vector' requires template
arguments
std::vector v;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:477:29:
note: template is declared here
class _LIBCPP_TYPE_VIS_ONLY vector
^
1 error generated.
This isn't:
$ cat test.cc
#include
#include
void f() {
std::vector v;
}
$ clang -c test.cc
test.cc:5:8: error: no type named 'vector' in namespace 'std'; did you mean
'hecto'?
std::vector v;
~^~
hecto
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ratio:265:43:
note: 'hecto' declared here
typedef ratio<100LL, 1LL> hecto;
^
1 error generated.
We probably should prefer the original diagnostic if there's a template with an
edit distance of 0 that's just missing the type parameters.
--
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 26642] New: Miscompilation caused by stack adjustment code clobbering used registers
https://llvm.org/bugs/show_bug.cgi?id=26642
Bug ID: 26642
Summary: Miscompilation caused by stack adjustment code
clobbering used registers
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: andrew.b.ad...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Some time on Friday one of the Halide tests starting returning wrong values on
the arm64 buildbot:
http://buildbot.halide-lang.org:8010/builders/arm64-linux-64-trunk/builds/69
(Halide is a language built on LLVM. Our buildbots pull and test against trunk
llvm every four hours or so.)
The cause seems to be stack adjustment code that clobbers an in-use register.
Below is .ll from llvm 3.7, and the asm it produces, and .ll from trunk llvm,
and the asm it produces. Pay attention to x9. It's the address of one of the
outputs (the one that's coming out as wrong).
In the working code, x9 is used as a temporary to adjust the stack downwards,
and then is loaded from [x1], and then used as the address to write the output
to near the end of the function (str w11, [x9])
In the broken code, x9 is loaded from the argument, *then* used as a temporary
to adjust the stack downward (clobbering it), and then used as an address to
write to by the same store instruction. This now becomes a useless store to the
stack instead of actually writing the output value.
Good ll and asm:
; ModuleID = 'halide_module_f10'
target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
target triple = "aarch64--linux-gnueabihf"
%struct.halide_filter_argument_t = type { i8*, i32, i32, i32, i32,
%struct.halide_scalar_value_t*, %struct.halide_scalar_value_t*,
%struct.halide_scalar_value_t* }
%struct.halide_scalar_value_t = type { %union.anon }
%union.anon = type { double }
%struct.halide_filter_metadata_t = type { i32, i32,
%struct.halide_filter_argument_t*, i8*, i8* }
%struct.buffer_t = type { i64, i8*, [4 x i32], [4 x i32], [4 x i32], i32, i8,
i8, [2 x i8] }
@str = private constant [6 x i8] c"f10.0\00", align 32
@str.2 = private constant [6 x i8] c"f10.1\00", align 32
@0 = private constant [2 x %struct.halide_filter_argument_t]
[%struct.halide_filter_argument_t { i8* getelementptr inbounds ([6 x i8], [6 x
i8]* @str, i32 0, i32 0), i32 2, i32 0, i32 0, i32 32,
%struct.halide_scalar_value_t* null, %struct.halide_scalar_value_t* null,
%struct.halide_scalar_value_t* null }, %struct.halide_filter_argument_t { i8*
getelementptr inbounds ([6 x i8], [6 x i8]* @str.2, i32 0, i32 0), i32 2, i32
0, i32 0, i32 32, %struct.halide_scalar_value_t* null,
%struct.halide_scalar_value_t* null, %struct.halide_scalar_value_t* null }]
@str.3 = private constant [35 x i8] c"arm-64-linux-no_asserts-no_runtime\00",
align 32
@str.4 = private constant [4 x i8] c"f10\00", align 32
@f10_metadata = constant %struct.halide_filter_metadata_t { i32 0, i32 2,
%struct.halide_filter_argument_t* getelementptr inbounds ([2 x
%struct.halide_filter_argument_t], [2 x %struct.halide_filter_argument_t]* @0,
i32 0, i32 0), i8* getelementptr inbounds ([35 x i8], [35 x i8]* @str.3, i32 0,
i32 0), i8* getelementptr inbounds ([4 x i8], [4 x i8]* @str.4, i32 0, i32 0) }
; Function Attrs: nounwind
define i32 @__f10(%struct.buffer_t* noalias nocapture %f10.0.buffer,
%struct.buffer_t* noalias nocapture %f10.1.buffer) #0 {
entry:
%f8.0.host59 = alloca [13 x <8 x i32>], align 32
%f8.1.host60 = alloca [13 x <8 x i32>], align 32
%buf_host = getelementptr inbounds %struct.buffer_t, %struct.buffer_t*
%f10.0.buffer, i64 0, i32 1
%f10.0.host = load i8*, i8** %buf_host, align 8
%buf_dev = getelementptr inbounds %struct.buffer_t, %struct.buffer_t*
%f10.0.buffer, i64 0, i32 0
%f10.0.dev = load i64, i64* %buf_dev, align 8
%0 = icmp eq i64 %f10.0.dev, 0
%1 = icmp eq i8* %f10.0.host, null
%f10.0.host_and_dev_are_null = and i1 %1, %0
%buf_host10 = getelementptr inbounds %struct.buffer_t, %struct.buffer_t*
%f10.1.buffer, i64 0, i32 1
%f10.1.host = load i8*, i8** %buf_host10, align 8
%buf_dev11 = getelementptr inbounds %struct.buffer_t, %struct.buffer_t*
%f10.1.buffer, i64 0, i32 0
%f10.1.dev = load i64, i64* %buf_dev11, align 8
%2 = icmp eq i64 %f10.1.dev, 0
%3 = icmp eq i8* %f10.1.host, null
%f10.1.host_and_dev_are_null = and i1 %3, %2
br i1 %f10.0.host_and_dev_are_null, label %true_bb, label %after_bb
true_bb: ; preds = %entry
%buf_elem_size27 = getelementptr inbounds %struct.buffer_t, %struct.buffer_t*
%f10.0.buffer, i64 0, i32 5
store i32 4, i32* %buf_elem_size27, align 4
%buf_extent29 = getelementptr inbounds %struct.buffer_t, %struct.buffer_t*
%f10.0.buffer, i64 0, i32 2, i64 0
%4 = bitcast i32* %buf_extent29 to i8*
call void @llvm.memset.p0i8.i64(i8* %4, i8
[llvm-bugs] [Bug 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 26316, which changed state. Bug 26316 Summary: [mips] Sanitizer regressions https://llvm.org/bugs/show_bug.cgi?id=26316 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 26316] [mips] Sanitizer regressions
https://llvm.org/bugs/show_bug.cgi?id=26316 Daniel Sanders changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Daniel Sanders --- Marking this resolved since the failures turned out to be mips64 related and are therefore not release blockers. -- 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 24461] Allow LLDB to support Python 3.5
https://llvm.org/bugs/show_bug.cgi?id=24461 Zachary Turner 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 26110] clang c compiler produces wrong result for the attached c code with -O2 optimzation
https://llvm.org/bugs/show_bug.cgi?id=26110 Ahmed Bougacha changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ahmed Bougacha --- Committed: r261025 [X86] Remove the now-unused X86ISD::PSIGN. NFC. r261024 [X86] Generalize logic blend of (x, -x) combine to match (-x, x). r261023 [X86] Don't turn (c?-v:v) into (c?-v:0) by blindly using PSIGN. r261022 [X86] Extract PSIGN/BLENDVP tests into vector-blend.ll. NFC. r261021 [X86] Extract PSIGN/BLENDVP combine. NFC. r261020 [X86] Extract ANDNP combine. NFC. -- 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 26643] New: False positive "format string is not a string literal", SARD #149064
https://llvm.org/bugs/show_bug.cgi?id=26643
Bug ID: 26643
Summary: False positive "format string is not a string
literal", SARD #149064
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: test35...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15912
--> https://llvm.org/bugs/attachment.cgi?id=15912&action=edit
SARD #149064 (
(This is the first bug report discovered by one of the SARD tests that I'm
integrating)
The attached file, downloaded from the page at:
https://samate.nist.gov/SARD/view_testcase.php?tID=149064
...file url: https://samate.nist.gov/SARD/testcases/000/149/064/fmt5-good.c
causes a false positive "format string is not a string literal".
The function in question:
void
test(char *fmt, char *str)
{
printf(fmt, str);/* FIX */
}
Is called with string literals as fmt:
if(userstr[0] == '!')
test("<%s>", userstr);
else
test("[%s]", userstr);
--
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 26644] New: False positive "format string is not a string literal", SARD #149064
https://llvm.org/bugs/show_bug.cgi?id=26644
Bug ID: 26644
Summary: False positive "format string is not a string
literal", SARD #149064
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: test35...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
(This is the first bug report discovered by one of the SARD tests that I'm
integrating)
The attached file, downloaded from the page at:
https://samate.nist.gov/SARD/view_testcase.php?tID=149064
...file url: https://samate.nist.gov/SARD/testcases/000/149/064/fmt5-good.c
causes a false positive "format string is not a string literal".
The function in question:
void
test(char *fmt, char *str)
{
printf(fmt, str);/* FIX */
}
Is called with string literals as fmt:
if(userstr[0] == '!')
test("<%s>", userstr);
else
test("[%s]", userstr);
...this may not be visible from a local analysis of `test`, which would cause
the warning.
--
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 26644] False positive "format string is not a string literal", SARD #149064
https://llvm.org/bugs/show_bug.cgi?id=26644 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #1 from Richard Smith --- *** This bug has been marked as a duplicate of bug 26643 *** -- 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 26643] False positive "format string is not a string literal", SARD #149064
https://llvm.org/bugs/show_bug.cgi?id=26643 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #3 from Richard Smith --- See the documentation here: http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format The format argument is not a string literal, and 'test' is not annotated with the 'format' attribute to indicate that 'fmt' is in fact a format string. So this is working as designed and intended. -- 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 26575] Assertion: "Address displacement operand is always an immediate or a global"
https://llvm.org/bugs/show_bug.cgi?id=26575 Hans Wennborg changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Hans Wennborg --- Sorry, same assert still firing after the pass was enabled again this morning. To reproduce: clang -cc1 -triple i686-pc-windows-msvc18.0.0 -emit-obj -target-cpu pentium4 -Os -fms-extensions -fms-compatibility -fms-compatibility-version=18.0 -std=c++11 -fno-threadsafe-statics -fdelayed-template-parsing -x c++ /tmp/a.ii -- 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] New: [LIR] Non-temporal aspect dropped via conversion to memset in some cases
https://llvm.org/bugs/show_bug.cgi?id=26645
Bug ID: 26645
Summary: [LIR] Non-temporal aspect dropped via conversion to
memset in some cases
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: warren_ris...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15914
--> https://llvm.org/bugs/attachment.cgi?id=15914&action=edit
test.ll
In the C++ test-case below (the associated "test.ll" file is attached), a loop
that clears a block of memory does so with non-temporal stores via the builtin:
__builtin_ia32_movntps(__p, __a);
(This is from the __mm_stream_ps() intrinsic, originally via an include of
.)
Prior to r258620, the stores were done via the non-temporal store instruction
'movntps'. With r258620, the loop is transformed to a memset() call, and so
the non-temporal aspect is lost, causing a performance regression relative to
llvm 3.8.
(Side note: r258620 was reverted at r258703, and an updated version was
re-submitted at r258777. The same behavior happens at r258777, as well as
current ToT (tested r261028).)
It's understood that this is a code-performance issue due to cache pollution.
That is, the correct answer is computed irrespective of whether the
non-temporal store instructions are generated, or whether the memset() call is
used. This is analogous to the situation of bug 19370, where the non-temporal
aspect was lost in some situations, resulting in a performance loss due to
cache pollution.
Note that the loop trip count in the case below is a constant. The loop is of
the form:
for ( unsigned int index = 0; index < sizeof( bigBlock_t ); index += 32 ) {
..
}
If the trip-count is a global variable, for example:
unsigned int theSize = sizeof( bigBlock_t );
and the loop is changed to:
for ( unsigned int index = 0; index < theSize; index += 32 ) {
..
}
then the non-temporal store instructions are again produced.
_
$ cat test.cpp
typedef float __m128 __attribute__((__vector_size__(16)));
static __inline__ __m128
__attribute__((__always_inline__, __nodebug__, __target__("sse")))
_mm_setzero_ps(void)
{
return (__m128){ 0, 0, 0, 0 };
}
static __inline__ void
__attribute__((__always_inline__, __nodebug__, __target__("sse")))
_mm_stream_ps(float *__p, __m128 __a)
{
__builtin_ia32_movntps(__p, __a);
}
struct bigBlock_t {
__m128 data[256];
} __attribute__((aligned(128)));
extern void nontemporal_init( bigBlock_t *p );
void nontemporal_init( bigBlock_t *p ) {
float *dst = reinterpret_cast< float * >( p );
__m128 src = _mm_setzero_ps();
for ( unsigned int index = 0; index < sizeof( bigBlock_t ); index += 32 ) {
_mm_stream_ps( dst + 0, src );
_mm_stream_ps( dst + 4, src );
dst += 8;
}
}
$
The "test.ll", generated from using the r258619 build as shown below, is
attached:
$ clang++ --version
clang version 3.9.0 (trunk 258619)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /llvm/bin
$ clang++ -S -emit-llvm -O0 test.cpp # test.ll created here is attached
$
Using opt/llc from r258619, the 'movntps' instructions can be seen:
$ opt test.ll -O2 -S -o opt.ll# opt from r258619
$ llc opt.ll -o opt.s
$ grep movntps opt.s # 16 'movntps' instructions, since loop is unrolled
movntps %xmm0, (%rdi,%rax)
movntps %xmm0, 16(%rdi,%rax)
movntps %xmm0, 32(%rdi,%rax)
movntps %xmm0, 48(%rdi,%rax)
movntps %xmm0, 64(%rdi,%rax)
movntps %xmm0, 80(%rdi,%rax)
movntps %xmm0, 96(%rdi,%rax)
movntps %xmm0, 112(%rdi,%rax)
movntps %xmm0, 128(%rdi,%rax)
movntps %xmm0, 144(%rdi,%rax)
movntps %xmm0, 160(%rdi,%rax)
movntps %xmm0, 176(%rdi,%rax)
movntps %xmm0, 192(%rdi,%rax)
movntps %xmm0, 208(%rdi,%rax)
movntps %xmm0, 224(%rdi,%rax)
movntps %xmm0, 240(%rdi,%rax)
$ grep memset opt.s
$
Using opt/llc from r258620, the 'movntps' instructions are no longer there, and
instead there is a call to memset():
$ opt test.ll -O2 -S -o opt.ll# opt from r258620
$ llc opt.ll -o opt.s
$ grep movntps opt.s
$ grep memset opt.s
callq memset
$
--
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 26646] New: [Polly] FAIL: paq8p.execution_time triggered sporadically
https://llvm.org/bugs/show_bug.cgi?id=26646 Bug ID: 26646 Summary: [Polly] FAIL: paq8p.execution_time triggered sporadically 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 On our LNT buildbots, the paq8p.execution_time test fails sporadically without good reason. It would be interesting to investigate what is going on. -- 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
