[llvm-bugs] [Bug 21597] Any regular expression should not match an empty sequence if match_not_null is specified
https://llvm.org/bugs/show_bug.cgi?id=21597 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED CC||timshe...@gmail.com Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Fixed by r284881. -- 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 19851] regex does not correctly handle the regex "a*|b*"
https://llvm.org/bugs/show_bug.cgi?id=19851 Tim Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||timshe...@gmail.com Resolution|--- |FIXED --- Comment #9 from Tim Shen --- Fixed by r285352. -- 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 21751] regex iterator endless loop
https://llvm.org/bugs/show_bug.cgi?id=21751 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED CC||timshe...@gmail.com Resolution|--- |FIXED --- Comment #2 from Tim Shen --- PR21597 is fixed. Mark this as 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 28752] Assertion `Parent->isHidden() && "unexpectedly hidden decl"' failed.
https://llvm.org/bugs/show_bug.cgi?id=28752 Vassil Vassilev changed: What|Removed |Added Status|RESOLVED|REOPENED CC||benny@gmail.com Resolution|FIXED |--- --- Comment #7 from Vassil Vassilev --- I seems this issue reappears. It seems it is related to the reverted commit in (r284382). "Revert "Reinstate r281429, reverted in r281452, with a fix for its mishandling of" This reverts commit r284176. It still marks some modules as invisible that should be visible. Will follow up with the author with a test case. " -- 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 30818] New: Infinite loop in Reassociate
https://llvm.org/bugs/show_bug.cgi?id=30818
Bug ID: 30818
Summary: Infinite loop in Reassociate
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: bjorn.a.petters...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17507
--> https://llvm.org/bugs/attachment.cgi?id=17507&action=edit
Hangs in reassociate
When running "opt -reassociate" on the following program (also included as
attachment) we end up in an infinite loop:
define void @xor_deadloop() {
br label %endlabel
deadloop:
%1 = xor i32 %2, 7
%2 = xor i32 %1, 8
br label %deadloop
endlabel:
ret void
}
Problem was detected when doing randomized tests using csmith.
A dead loop similar to the example below was created by -jump-threading.
According to -verify the code is valid. However, the SSA form of the dead loop
is quite interesting.
--
One solution (to avoid hanging in Reassociate) is to simply avoid analysis of
dead basic blocks.
For example like this patch:
diff --git a/lib/Transforms/Scalar/Reassociate.cpp
b/lib/Transforms/Scalar/Reassociate.cpp
index 1ec7fce..6fc8dc8 100644
--- a/lib/Transforms/Scalar/Reassociate.cpp
+++ b/lib/Transforms/Scalar/Reassociate.cpp
@@ -2177,8 +2177,19 @@ PreservedAnalyses ReassociatePass::run(Function &F,
FunctionAnalysisManager &) {
// Calculate the rank map for F.
BuildRankMap(F);
+ // Mark all reachable blocks.
+ df_iterator_default_set Reachable;
+ for (BasicBlock *BB : depth_first_ext(&F, Reachable))
+(void)BB/* Mark all reachable blocks */;
+
MadeChange = false;
for (Function::iterator BI = F.begin(), BE = F.end(); BI != BE; ++BI) {
+// Skip dead basic blocks
+if (!Reachable.count(&*BI)) {
+ DEBUG(dbgs() << "Skipping dead BB:"; BI->dump(););
+ continue;
+}
+
// Optimize every instruction in the basic block.
for (BasicBlock::iterator II = BI->begin(), IE = BI->end(); II != IE;)
if (isInstructionTriviallyDead(&*II)) {
--
I noticed that this problem started to appear after this commit
(so it could be an old problem that appeared again after that revert):
commit a537a2bbfe75a0f15deb93efa5dd9f8ad96971e8
Author: Chad Rosier
Date: Wed Aug 17 15:54:39 2016 +
Revert "Reassociate: Reprocess RedoInsts after each inst".
This reverts commit r258830, which introduced a bug described in PR28367.
PR28367
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278938
91177308-0d34-0410-b5e6-96231b3b80d8
--
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 30820] New: Linker error: undefined reference to `std::vector<...>::~vector()
https://llvm.org/bugs/show_bug.cgi?id=30820
Bug ID: 30820
Summary: Linker error: undefined reference to
`std::vector<...>::~vector()
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: serguei.ko...@cern.ch
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Hi
I have recently encountered the problem of compiling some code which uses
std::vector class. Here is the minimal example which reproduces the problem:
#include
template
void f(I i, const std::vector & v = { 1, 2, 3}) {
}
int main(int , char**) {
f(1);
}
Here is the compiler output:
:> clang++ -std=c++14 t.cc
/tmp/kolos/ttt-460d3b.o: In function `main':
ttt.cc:(.text+0x61): undefined reference to `std::vector >::~vector()'
ttt.cc:(.text+0x92): undefined reference to `std::vector >::~vector()'
clang-3.9: error: linker command failed with exit code 1 (use -v to see
invocation)
Here are the system and compiler details
:> clang++ -v
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /external/llvm/3.9/x86_64-slc6/bin
Found candidate GCC installation:
/contrib/gcc/4.9/x86_64-slc6/lib/gcc/x86_64-unknown-linux-gnu/4.9.3
Selected GCC installation:
/contrib/gcc/4.9/x86_64-slc6/lib/gcc/x86_64-unknown-linux-gnu/4.9.3
Candidate multilib: .;@m64
Selected multilib: .;@m64
:> uname -a
Linux 2.6.32-642.6.1.el6.x86_64 #1 SMP Wed Oct 5 16:49:07 CEST 2016 x86_64
x86_64 x86_64 GNU/Linux
--
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 30582] Incorrect alignment in the indentation
https://llvm.org/bugs/show_bug.cgi?id=30582
Daniel Jasper changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Daniel Jasper ---
This behavior is intended as you basically have two different "binary"
operators in a set of parenthese: "&&" and ",". Thus, clang-format uses the
extra indentation to highlight that the second line is not just one more
parameter to the surrounding function call.
You can of course avoid that by either pulling out local variables or
surrounding the &&-expression with parentheses.
Again, this is intended. Imagine, you'd have an expression like:
function( &&
,
,
&&
,
);
Obviously this is fabricated, but I have seen many cases, where the extra
indentation makes the code significantly more obvious.
--
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 30821] New: Miscompile due to Stack Slot Coloring and partial load/stores
https://llvm.org/bugs/show_bug.cgi?id=30821
Bug ID: 30821
Summary: Miscompile due to Stack Slot Coloring and partial
load/stores
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: greg_bedw...@sn.scee.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
One of our random test generators found the following miscompile bug. Here's a
source-level repro-case (reduced and massaged a bit from the initial randomly
generated case to make it a bit less transient, with the added __asm__
statement):
// ===
extern "C" int printf(const char *, ...);
typedef double __m128d __attribute__((__vector_size__(16)));
__attribute__((noinline))
static void init(unsigned char pred, void *data, unsigned size) {
unsigned char *bytes = (unsigned char *)data;
for (unsigned i = 0; i != size; ++i) {
bytes[i] = pred + i;
}
}
int main() {
volatile unsigned char alpha = 1;
unsigned char bravo = alpha;
__m128d foxtrot;
for (unsigned char charlie = 0; charlie < bravo; ++charlie) {
for (unsigned char golf = 0; golf < 2; ++golf){
__asm__ volatile ("nop":::"ebx", "r8", "r9", "r12", "r13", "r14", "r15");
init(0xff, &foxtrot, sizeof(foxtrot));
}
}
volatile __m128d india = {23.0, 24.0};
printf("%lf %lf -> ", india[0], india[1]);
india[1] = 0.0;
printf("%lf %lf\n", india[0], india[1]);
}
// ===
$ ./build/bin/clang 1.cpp --version
clang version 4.0.0 (trunk 285395) (llvm/trunk 285397)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/greg/public_git/./build/bin
$ ./build/bin/clang 1.cpp -O0 -target x86_64-unknown-unknown -mavx -o 1.elf &&
./1.elf
23.00 24.00 -> 23.00 0.00
$ ./build/bin/clang 1.cpp -O2 -target x86_64-unknown-unknown -mavx -o 1.elf &&
./1.elf
23.00 24.00 -> 23.00 0.00
$ ./build/bin/clang 1.cpp -O1 -target x86_64-unknown-unknown -mavx -o 1.elf &&
./1.elf
23.00 24.00 -> 23.00 24.00
^ INCORRECT RESULT
Note the difference in the -O1 build result.
Here's our initial local analysis of the bug (from Andrea Di Biagio). Any help
appreciated.
~~~
~~~
The problem is caused by an incorrect simplification performed by the Stack
Slot Coloring pass.
The stack slot coloring pass attempts to reduce the number of stack slots
introduced by the
register allocator when inserting spill/reload code.
After register allocation, we may end up with code that looks similar to the
following pseudo-code:
1. SPILL_REGISTER(regA, SlotA);
2. ...
3. regB = RELOAD_REGISTER(SlotA);
4. SPILL_REGISTER(regB, SlotB);
5. ...
6. RegC = RELOAD_REGISTER(SlotB);
7. ...
///
Here we have two stack slots respectively named 'SlotA' and 'SlotB'.
SlotA is used to spill the value of 'regA'.
Later on, the value of 'regA' is reloaded into register 'regB'.
That register is also spilled in memory to a different stack location.
Eventually, it is reloaded
from stack into yet another register.
Pass Stack Slot Coloring is able to see that 'SlotA' is live between
instructions #1 and #3.
Stack slot 'SlotB' is live between instructions #4 and #6.
Since the liveness ranges for the two slots is disjoint, pass Stack Slot
Coloring attempts to reuse
the same stack slot for both spills/reloads. So we end up with code similar to
this:
1. SPILL_REGISTER(regA, SlotA);
2. ...
3. regB = RELOAD_REGISTER(SlotA);
4. SPILL_REGISTER(regB, SlotA);
5. ...
6. RegC = RELOAD_REGISTER(SlotA);
7. ...
///
So, we saved one stack location, and we exposed some redundancy in the code.
Now, the following two
instructions are redundant:
3. regB = RELOAD_REGISTER(SlotA);
4. SPILL_REGISTER(regB, SlotA);
Therefore, the Stack Slot Coloring pass removes the redundant spill/reload
sequence (3. and 4.).
The problem is that the Stack Slot Coloring pass uses two hook implemented by
the TTI (Target
Instruction Info) interface to figure out if an instruction is a "load from
stack slot" or a "store
to stack slot".
On x86, opcodes MOVSS/MOVSD/VMOVSS/VMOVSD are all valid opcodes for
loads/stores from/to stack
slots.
This is problematic because MOVSS/MOVSD/VMOVSS/VMOVSD are "partial
loads/stores" since those
operats on 32/64 bits only (instead of 128/256). In particular, MOVSSrm/MOVSDrm
are zero-extending
loads.
Let's then have a look at the following example:
1. VMOVUPDmr regA, SlotA;
2. ...
3. regB = VMOVSDrm SlotA;
4. VMOVUPDmr regB, SlotA;
5. ...
6. RegC = VM
[llvm-bugs] [Bug 30822] New: lldb-mi failing in llvm::CommandLine global constructor on debug builds
https://llvm.org/bugs/show_bug.cgi?id=30822 Bug ID: 30822 Summary: lldb-mi failing in llvm::CommandLine global constructor on debug builds Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified On Ubuntu 14.04 and 16.04 x86_64, I am seeing a failure to run lldb-mi due to an assert being raised on builds where NDEBUG is not defined. The failure is in a global constructor in LLVM's Debug.cpp file where it adds a 'debug' command line option. At the time the global constructor files, the StringDictionary where the option is being checked for existence seems to indicate it has something like 7k objects in it, which seems wrong. Running through valgrind doesn't show any memory stomps, though. Here is the CMake/ninja setup I'm using: # For Ubuntu 14.04 $ CC=clang-3.6 CXX=clang++-3.6 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm -DLLDB_EXPORT_ALL_SYMBOLS=TRUE $ ninja Here's the error: $ bin/lldb-mi : CommandLine Error: Option 'debug' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options I am wondering if: (a) our Ubuntu buildbots are seeing this behavior? (b) why we're not failing the build? This regression seems to have been introduced fairly recently, as I have downstream Ubuntu repositories that I directly manage (ci.swift.org) where we do run the lldb-mi tests on Ubuntu, and the lldb-mi failure seems to have only shown up after r281031. -- 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 30823] New: LLVM ERROR: Cannot select: t5: v16i8 = BUILD_VECTOR Constant:i32<1>,
https://llvm.org/bugs/show_bug.cgi?id=30823
Bug ID: 30823
Summary: LLVM ERROR: Cannot select: t5: v16i8 = BUILD_VECTOR
Constant:i32<1>,
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: jt...@ca.ibm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
jtony@genoa:~/scrum/s1/29$ cat test.ll
define <16 x i8> @test() {
entry:
ret <16 x i8>
}
jtony@genoa:~/scrum/s1/29$ llc < test.ll -mcpu=pwr9
.text
.abiversion 2
.file ""
LLVM ERROR: Cannot select: t5: v16i8 = BUILD_VECTOR Constant:i32<1>,
Constant:i32<2>, Constant:i32<3>, Constant:i32<4>, Constant:i32<1>,
Constant:i32<2>, Constant:i32<3>, Constant:i32<4>, Constant:i32<1>,
Constant:i32<2>, Constant:i32<3>, Constant:i32<4>, Constant:i32<1>,
Constant:i32<2>, Constant:i32<3>, Constant:i32<4>
t12: i32 = Constant<1>
t11: i32 = Constant<2>
t10: i32 = Constant<3>
t9: i32 = Constant<4>
t12: i32 = Constant<1>
t11: i32 = Constant<2>
t10: i32 = Constant<3>
t9: i32 = Constant<4>
t12: i32 = Constant<1>
t11: i32 = Constant<2>
t10: i32 = Constant<3>
t9: i32 = Constant<4>
t12: i32 = Constant<1>
t11: i32 = Constant<2>
t10: i32 = Constant<3>
t9: i32 = Constant<4>
In function: test
Note this bug only occurs with option -mcpu=pwr9.
--
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 30824] New: lldb evaluates $N incorrectly when it was a printed register value
https://llvm.org/bugs/show_bug.cgi?id=30824
Bug ID: 30824
Summary: lldb evaluates $N incorrectly when it was a printed
register value
Product: lldb
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: r...@swtch.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Using Ubuntu 14.04 LTS's lldb-3.8 package to debug a trivial program, try
printing a register value (first print, so it ends up being $0) and then
referring to that print in a later expression. The later reference is
incorrectly evaluated:
$ echo 'int main() {return 0;}' | gcc -xc - -o a.out # any binary will do
$ lldb-3.8 --version
lldb version 3.8.0 ( revision )
$ lldb-3.8 a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main, address = 0x004004ed
(lldb) r
Process 62061 launched: '/usr/local/google/home/rsc/a.out' (x86_64)
Process 62061 stopped
* thread #1: tid = 62061, 0x004004ed a.out`main, name = 'a.out', stop
reason = breakpoint 1.1
frame #0: 0x004004ed a.out`main
a.out`main:
-> 0x4004ed <+0>: pushq %rbp
0x4004ee <+1>: movq %rsp, %rbp
0x4004f1 <+4>: movl $0x0, %eax
0x4004f6 <+9>: popq %rbp
(lldb) print/x $rdi
(unsigned long) $0 = 0x0001
(lldb) print/x ($rdi)
(unsigned long) $1 = 0x0001
(lldb) print/x $0
(unsigned long) $0 = 0x0001
(lldb) print/x ($0)
(unsigned long) $2 = 0x77ff6008 <<< WRONG!
(lldb)
$0 and ($0) should evaluate to the same value. The final print is wrong. This
happens in any non-trivial expression involving printed register values.
Continuing:
(lldb) print/x $rdi
(unsigned long) $3 = 0x0001
(lldb) print/x $rsi
(unsigned long) $4 = 0x7fffe058
(lldb) print/x $rdi+$rsi
(unsigned long) $5 = 0x7fffe059
(lldb) print/x $3+$4
(unsigned long) $6 = 0xeffec010 <<< WRONG!
(lldb)
And so on.
I see this on OS X with the Xcode toolchain lldb as well.
--
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 30825] New: Dont generate __powi{d, s}f2 calls for Windows
https://llvm.org/bugs/show_bug.cgi?id=30825
Bug ID: 30825
Summary: Dont generate __powi{d,s}f2 calls for Windows
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: compn...@compnerd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Calls to `@llvm.powi.f64` and `@llvm.powi.f32` generate calls to
`__powi{d,s}f2` on Windows. These should be reduced to calls to `powf` with
the appropriate casts.
--
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 30826] New: commit 3dd46201c189fb17da44fb4457afe692ad5dd5d9
https://llvm.org/bugs/show_bug.cgi?id=30826 Bug ID: 30826 Summary: commit 3dd46201c189fb17da44fb4457afe692ad5dd5d9 Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: minseong@linaro.org CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified commit 3dd46201c189fb17da44fb4457afe692ad5dd5d9 merged at Oct 28 causes the following error when building with clang: llvm/projects/libcxx/include/__config:912:38: error: expected unqualified-id before string constant _LIBCPP_FUNC_VIS _LIBCPP_WEAK extern "C++" int __libcpp_library_version(); Should be reverted ? -- 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 30827] New: [mc] No checks for immediate operands size
https://llvm.org/bugs/show_bug.cgi?id=30827 Bug ID: 30827 Summary: [mc] No checks for immediate operands size Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: i.am.permi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified If immediate operand doesn't fit into instruction assembler just silently truncates it. For example: s_mulk_i32 s2, 0x8000 * 4 Assembler will produce following isa without any warning or error: s_mulk_i32 s2, 0x // 077C: B782 We need to check such cases and show appropriate message (error). -- 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 30828] New: __attribute__((notnull)) in prototype's parameter is forgotten after function definition
https://llvm.org/bugs/show_bug.cgi?id=30828
Bug ID: 30828
Summary: __attribute__((notnull)) in prototype's parameter is
forgotten after function definition
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: t...@iki.fi
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Using __attribute__((notnull)) in prototype's parameter works as long as the
function definition hasn't been seen. Afterwards the notnull attribute is lost
and no more warnings are given. This same problem doesn't happen when using
__attribute__((notnull(1))) style.
Example:
//static void foo(char *p) __attribute__((nonnull(1))); // 2 warnings
static void foo(char *p __attribute__((nonnull))); // 1 warning
static void bar(char *p)
{
foo(0); // always gets a warning
}
static void foo(char *p) { }
int main(void)
{
foo(0); // warning missing here
bar(0);
return 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 30829] New: [mc][gfx8] No checks for ADDC/SUBB/V_CNDMASK source operand restrictions
https://llvm.org/bugs/show_bug.cgi?id=30829 Bug ID: 30829 Summary: [mc][gfx8] No checks for ADDC/SUBB/V_CNDMASK source operand restrictions Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: artem.tama...@amd.com Reporter: i.am.permi...@gmail.com CC: andrey.kasau...@gmail.com, artem.tama...@amd.com, i.am.permi...@gmail.com, llvm-bugs@lists.llvm.org, nikolay.haus...@amd.com, sam.kol...@amd.com, valery.pykh...@gmail.com Classification: Unclassified SGPR, M0, EXEC or literal constant are not allowed for ADDC/SUBB/V_CNDMASK instructions. Still assembler allows illegal encodings like: v_addc_u32 v40, vcc, s49, 0, vcc -- 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 30830] New: LLD linker script test failure on AArch64
https://llvm.org/bugs/show_bug.cgi?id=30830
Bug ID: 30830
Summary: LLD linker script test failure on AArch64
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: renato.go...@linaro.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
It seems LLD is calculating offsets wrong in AArch64:
ELF/linkerscript/locationcounter.s
# RUN: . = 0x3 + (1 + 1023 >> 2); \
# RUN: .shiftr : { *(.shiftr) }
...
test/ELF/linkerscript/locationcounter.s:74:10: error: expected string not found
in input
# CHECK: .shiftr {{.*}} 00030100
^
:26:39: note: scanning from here
20 .shiftl 0008 00030040 DATA
^
:27:3: note: possible intended match here
21 .shiftr 0008 00030400 DATA
^
It should not be 0x30400, but the expected 0x30100
--
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 30826] commit 3dd46201c189fb17da44fb4457afe692ad5dd5d9
https://llvm.org/bugs/show_bug.cgi?id=30826 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Fiselier --- I'm pretty sure your using GCC not Clang, unless GCC and Clang emit letter-for-letter identical errors. -- 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 30831] New: Parser segmentation fault
https://llvm.org/bugs/show_bug.cgi?id=30831
Bug ID: 30831
Summary: Parser segmentation fault
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: jj.oconno...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17508
--> https://llvm.org/bugs/attachment.cgi?id=17508&action=edit
contains test.cpp, the stack traces from 3.8 and 3.9, the above text, and the
/tmp files those stacks told me to include with a bug report
I wrote some nonsense code by accident and segfaulted the parser. It's short
enough to fit in here (it's only 8 lines):
__
template
class A {
public:
static A const a;
};
template
A A::a = A();
__
The parser says it was on the token '=' when it died.
The compiler (specifically the parse step) crashes with this invocation:
$ clang++ test.cpp
Also:
$ clang++-3.9 test.cpp
Here's some OS and version information:
$ clang++ --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ clang++-3.9 --version
clang version 3.9.0-svn275918-1~exp1 (branches/release_39)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
NAME="Ubuntu"
VERSION="16.04.1 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.1 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/";
SUPPORT_URL="http://help.ubuntu.com/";
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
UBUNTU_CODENAME=xenial
$ uname -a
Linux refraction 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
--
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 30832] New: Can't fold a reload if spill size doesn't match use size
https://llvm.org/bugs/show_bug.cgi?id=30832
Bug ID: 30832
Summary: Can't fold a reload if spill size doesn't match use
size
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This is something we currently explicitly don't do because targets aren't
required to support it (InlinerSpiller::foldMemoryOperand()).
So for:
target triple = "x86_64-unknown-linux-gnu"
define i32 @foo(i64 %add, i32 %ret) {
entry:
tail call void asm sideeffect "",
"~{rax},~{rbx},~{rcx},~{rdx},~{rdi},~{rbp},~{r8},~{r9},~{r10},~{r11},~{r12},~{r13},~{r14},~{r15},~{dirflag},~{fpsr},~{flags}"()
%conv3 = zext i32 %ret to i64
%sub = sub i64 %conv3, %add
%conv1 = trunc i64 %sub to i32
ret i32 %conv1
}
we generate:
[...]
movq%rdi, -8(%rsp) # 8-byte Spill
movq-8(%rsp), %rax # 8-byte Reload
subl%eax, %esi
[...]
The same also happens for vector registers (spill ymm, reload ymm, use xmm).
--
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 30831] Parser segmentation fault
https://llvm.org/bugs/show_bug.cgi?id=30831 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |FIXED --- Comment #1 from Richard Smith --- Fixed in r285437. -- 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 30833] New: [ppc] Use cmplwi insead of rlwinm. to compare bool var
https://llvm.org/bugs/show_bug.cgi?id=30833
Bug ID: 30833
Summary: [ppc] Use cmplwi insead of rlwinm. to compare bool var
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compile the following code with options -m64 -O2
struct A {
long V() const { return f4 ? f1: f2; }
bool IsDone() const { return f3 >= V(); }
long f1, f2;
int f3;
bool f4;
};
struct B {
bool IsDone() const { return f6 >= f5.f1; }
void Next();
A f5;
int f6;
};
extern A qux();
extern B bar();
void B::Next() {
while (f5.IsDone()) {
f5 = qux();
}
}
void foo() {
B iter = bar();
while (!iter.IsDone()) {
iter.Next();
}
}
LLVM generates:
...
lwz 4, 112(31)
lbz 5, 116(31)
ld 7, 104(31)
addi 29, 31, 128
.p2align4
.LBB1_2:# %while.body
# =>This Loop Header: Depth=1
# Child Loop BB1_3 Depth 2
rlwinm. 8, 5, 0, 24, 31 // A
extsw 8, 4
isel 9, 7, 3, 2
cmpd 8, 9
blt 0, .LBB1_5
.p2align4
.LBB1_3:# %while.body.i
# Parent Loop BB1_2 Depth=1
# => This Inner Loop Header: Depth=2
mr 3, 29
bl _Z3quxv
nop
lxvd2x 0, 0, 29
stxvd2x 0, 0, 30
ori 2, 2, 0
ld 3, 144(31)
std 3, 112(31)
ori 2, 2, 0
lbz 5, 116(31)
ld 3, 96(31)
ld 7, 104(31)
lwa 4, 112(31)
cmplwi 5, 0 // B
isel 6, 7, 3, 2
cmpd 4, 6
bge 0, .LBB1_3
# BB#4: # %while.cond.backedge.loopexit
# in Loop: Header=BB1_2 Depth=1
lwz 6, 120(31)
.LBB1_5:# %while.cond.backedge
# in Loop: Header=BB1_2 Depth=1
extsw 8, 6
cmpd 8, 3
blt 0, .LBB1_2
...
Note that instruction A is actually comparing a bool variable loaded from
116(31), it can be replaced with a slightly faster instruction cmplwi, just
like instruction B.
--
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 30834] New: Merge r283427 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30834 Bug ID: 30834 Summary: Merge r283427 into the 3.9 branch Product: libraries Version: 3.9 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: tav...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 30261 Classification: Unclassified cygwin build fix -- 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
