[llvm-bugs] [Bug 38590] Clang doesn't use add with carry when adding constants
https://bugs.llvm.org/show_bug.cgi?id=38590 Ilya Lesokhin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ilya Lesokhin --- *** This bug has been marked as a duplicate of bug 31754 *** -- 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 39375] False positive -Wcomma with static_cast of dependent expression
https://bugs.llvm.org/show_bug.cgi?id=39375 rtr...@google.com changed: What|Removed |Added CC||rtr...@google.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from rtr...@google.com --- Fixed in r345111. -- 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 39414] Poor code generation for NEON unaligned loads/stores
https://bugs.llvm.org/show_bug.cgi?id=39414 Fabian Giesen 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 39415] clang-cl rejects dllexport on things in anonymous namespaces but MSVC accepts
https://bugs.llvm.org/show_bug.cgi?id=39415 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Reid Kleckner --- Closing to indicate that we have no plans to work on this, please comment if this affects you. -- 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 39415] New: MSVC rejects dllexport on things in anonymous namespaces but MSVC accepts
https://bugs.llvm.org/show_bug.cgi?id=39415
Bug ID: 39415
Summary: MSVC rejects dllexport on things in anonymous
namespaces but MSVC accepts
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Consider:
$ cat t.cpp
namespace {
int __declspec(dllexport) foo() { return 1; }
int __declspec(dllexport) bar = 42;
}
$ cl -c t.cpp
# no errors
$ clang-cl -c t.cpp
t.cpp(2,27): error: '(anonymous namespace)::foo' must have external linkage
when declared 'dllexport'
int __declspec(dllexport) foo() { return 1; }
^
t.cpp(3,27): error: '(anonymous namespace)::bar' must have external linkage
when declared 'dllexport'
int __declspec(dllexport) bar = 42;
^
However, if you use 'static', MSVC doesn't like it:
$ cat t.cpp
static int __declspec(dllexport) foo() { return 1; }
static int __declspec(dllexport) bar = 42;
$ cl -c t.cpp
t.cpp(1): error C2201: 'foo': must have external linkage in order to be
exported/imported
t.cpp(2): error C2201: 'bar': must have external linkage in order to be
exported/imported
We followed them in implementing our version of this diagnostic.
I think it's pretty clear that MSVC's behavior is just behavior that emerged
from past C++ standard guidance that things in anonymous namespaces used to
have external linkage, but now they do not. MSVC probably reduced their linkage
to static, ran into compatibility issues with code like this, and went back to
their old behavior.
I'm mostly filing this so I can close it as WONTFIX, but if more users run into
this over time, please comment here, and we can re-evaluate.
--
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 39414] New: Poor code generation for NEON unaligned loads/stores
https://bugs.llvm.org/show_bug.cgi?id=39414
Bug ID: 39414
Summary: Poor code generation for NEON unaligned loads/stores
Product: libraries
Version: 7.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: fabi...@radgametools.com
CC: llvm-bugs@lists.llvm.org
Sample repro on Godbolt:
https://godbolt.org/z/itWjaD
Here's the (C++) code verbatim:
#include
typedef uint32_t U32unalign __attribute__((aligned(1)));
void f_unalign(void *p, uint8x8_t v)
{
vst1_lane_u32((U32unalign *) p, vreinterpret_u32_u8(v), 0);
}
void f_align(void *p, uint8x8_t v)
{
vst1_lane_u32((uint32_t *) p, vreinterpret_u32_u8(v), 0);
}
uint8x8_t g_unalign(const void *p)
{
return vld1_dup_u32((U32unalign *)p);
}
uint8x8_t g_align(const void *p)
{
return vld1_dup_u32((uint32_t *)p);
}
clang -target armv7a-none-eabi -O2 -S produces:
f_unalign(void*, __simd64_uint8_t):
vmovd16, r2, r3
vmov.32 r1, d16[0]
strbr1, [r0]
lsr r2, r1, #24
strbr2, [r0, #3]
lsr r2, r1, #16
lsr r1, r1, #8
strbr2, [r0, #2]
strbr1, [r0, #1]
bx lr
f_align(void*, __simd64_uint8_t):
vmovd16, r2, r3
vst1.32 {d16[0]}, [r0:32]
bx lr
g_unalign(void const*):
ldrbr1, [r0]
ldrbr2, [r0, #1]
ldrbr3, [r0, #2]
ldrbr0, [r0, #3]
orr r1, r1, r2, lsl #8
orr r0, r3, r0, lsl #8
orr r0, r1, r0, lsl #16
vdup.32 d16, r0
vmovr0, r1, d16
bx lr
g_align(void const*):
vld1.32 {d16[]}, [r0:32]
vmovr0, r1, d16
bx lr
The code I would expect to see for the unaligned variants is:
f_unalign(void*, __simd64_uint8_t):
vmovd16, r2, r3
vst1.32 {d16[0]}, [r0] ; same as f_align except for :32 alignment
specifier
bx lr
g_unalign(void const*):
vld1.32 {d16[]}, [r0] ; same here
vmovr0, r1, d16
bx lr
This is especially awkward with the NEON intrinsics because the single-lane
variants of vst1.32 (or .16) can be used to either:
- Store a single 32-bit lane (the intrinsics are OK for this)
- Store contiguous 32 bits (or 16 bits) of a narrower type, which the
intrinsics can't really express, requiring awkward workarounds like the
"U32unalign" construction above.
--
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 38747] lld -r omits .note.GNU-stack (implying executable stack to bfd/gold)
https://bugs.llvm.org/show_bug.cgi?id=38747 Ryan Prichard 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 39413] New: GlobalMerge optimization drops visibility attributes
https://bugs.llvm.org/show_bug.cgi?id=39413
Bug ID: 39413
Summary: GlobalMerge optimization drops visibility attributes
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: rprich...@google.com
CC: llvm-bugs@lists.llvm.org
The GlobalMerge optimization enabled with -Oz or -O3 appears to discard
visibility attributes from variables. The merged variables have default
visibility when they were declared as hidden or protected.
int somevar1 __attribute__((visibility("hidden"))) = 1;
int somevar2 __attribute__((visibility("hidden"))) = 2;
int somevar3 __attribute__((visibility("protected"))) = 1;
int somevar4 __attribute__((visibility("protected"))) = 2;
int get12() {
return somevar1 + somevar2;
}
int get34() {
return somevar3 + somevar4;
}
$ clang -target arm -Oz test.c -c && readelf -s test.o | grep somevar
11: 4 OBJECT GLOBAL DEFAULT6 somevar1
12: 0004 4 OBJECT GLOBAL DEFAULT6 somevar2
13: 0008 4 OBJECT GLOBAL DEFAULT6 somevar3
14: 000c 4 OBJECT GLOBAL DEFAULT6 somevar4
$ clang -target arm -Oz test.c -c -mno-global-merge && readelf -s test.o | grep
somevar
9: 4 OBJECT GLOBAL HIDDEN 6 somevar1
10: 0004 4 OBJECT GLOBAL HIDDEN 6 somevar2
11: 0008 4 OBJECT GLOBAL PROTECTED6 somevar3
12: 000c 4 OBJECT GLOBAL PROTECTED6 somevar4
This was originally reported against the Android NDK
(https://github.com/android-ndk/ndk/issues/829).
--
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 39412] New: [Format/ObjC] Incorrect spacing before array subscript operation containing ObjC method call
https://bugs.llvm.org/show_bug.cgi?id=39412
Bug ID: 39412
Summary: [Format/ObjC] Incorrect spacing before array subscript
operation containing ObjC method call
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: bhamilto...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
clang-format currently incorrectly inserts a space between an identifier and an
array subscript operation when the value of the index is the result of an
Objective-C method call:
% cat /tmp/test.m
foo[[Bar() blech]];
% ./bin/clang-format -debug /tmp/test.m
Args: ./bin/clang-format -debug /tmp/test.m
Trying /tmp/.clang-format...
Trying /tmp/_clang-format...
Trying /.clang-format...
Trying /_clang-format...
File encoding: UTF8
Language: Objective-C
Line(0, FSC=0): identifier[T=68, OC=0] l_square[T=68, OC=3] l_square[T=68,
OC=4] identifier[T=68, OC=5] l_paren[T=68, OC=8] r_paren[T=68, OC=9]
identifier[T=68, OC=11] r_square[T=68, OC=16] r_square[T=68, OC=17] semi[T=68,
OC=18]
Line(0, FSC=0): eof[T=68, OC=0]
Run 0...
AnnotatedTokens(L=0):
M=0 C=0 T=Unknown S=1 B=0 BK=0 P=0 Name=identifier L=3 PPK=2 FakeLParens=
FakeRParens=0 II=0x5610d7887bb0 Text='foo'
M=0 C=1 T=AttributeSquare S=1 B=0 BK=0 P=23 Name=l_square L=5 PPK=2
FakeLParens= FakeRParens=0 II=0x0 Text='['
M=0 C=1 T=AttributeSquare S=0 B=0 BK=0 P=59 Name=l_square L=6 PPK=2
FakeLParens= FakeRParens=0 II=0x0 Text='['
M=0 C=0 T=Unknown S=0 B=0 BK=0 P=79 Name=identifier L=9 PPK=2 FakeLParens=
FakeRParens=0 II=0x5610d7887be0 Text='Bar'
M=0 C=0 T=Unknown S=0 B=0 BK=0 P=63 Name=l_paren L=10 PPK=2 FakeLParens=
FakeRParens=0 II=0x0 Text='('
M=0 C=0 T=Unknown S=0 B=0 BK=0 P=99 Name=r_paren L=11 PPK=2 FakeLParens=
FakeRParens=0 II=0x0 Text=')'
M=0 C=1 T=Unknown S=1 B=0 BK=0 P=63 Name=identifier L=17 PPK=2 FakeLParens=
FakeRParens=0 II=0x5610d7887c10 Text='blech'
M=0 C=0 T=AttributeSquare S=0 B=0 BK=0 P=63 Name=r_square L=18 PPK=2
FakeLParens= FakeRParens=0 II=0x0 Text=']'
M=0 C=0 T=AttributeSquare S=0 B=0 BK=0 P=43 Name=r_square L=19 PPK=2
FakeLParens= FakeRParens=0 II=0x0 Text=']'
M=0 C=0 T=Unknown S=0 B=0 BK=0 P=23 Name=semi L=20 PPK=2 FakeLParens=
FakeRParens=0 II=0x0 Text=';'
AnnotatedTokens(L=0):
M=0 C=0 T=Unknown S=1 B=0 BK=0 P=0 Name=eof L=0 PPK=2 FakeLParens=
FakeRParens=0 II=0x0 Text=''
Replacements for run 0:
/tmp/test.m: 3:+0:" "
foo [[Bar() blech]];
--
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 15071] redefinition of enumerator in enum not issuing an error
https://bugs.llvm.org/show_bug.cgi?id=15071 Aaron Ballman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Aaron Ballman --- Fixed in r345073. -- 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 39411] New: Merge r339424 into the 7.0 branch: clang-cl: accept -fcrash-diagnostics-dir=
https://bugs.llvm.org/show_bug.cgi?id=39411 Bug ID: 39411 Summary: Merge r339424 into the 7.0 branch: clang-cl: accept -fcrash-diagnostics-dir= Product: new-bugs Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: llvm-bugs@lists.llvm.org Blocks: 39106 Trivial driver fix for easier crash reporting on Windows. https://github.com/llvm-mirror/clang/commit/8c7ddf2e8931f8aeebd6cb80701bd58cdbc31c7a Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39106 [Bug 39106] [meta] 7.0.1 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 39398] [DAG] Assertion `N->getOpcode() != ISD::DELETED_NODE && "Deleted Node added to Worklist"' failed.
https://bugs.llvm.org/show_bug.cgi?id=39398 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||345070 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- Reverted in rL345070 and added a reduced 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 39354] Potential undefined behaviour in the ctor for vector
https://bugs.llvm.org/show_bug.cgi?id=39354 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #8 from Marshall Clow (home) --- Committed revision 345067 to fix this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39410] New: [IA] clang hangs with `-no-integrated-as -Wa, -`
https://bugs.llvm.org/show_bug.cgi?id=39410
Bug ID: 39410
Summary: [IA] clang hangs with `-no-integrated-as -Wa,-`
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: ndesaulni...@google.com
CC: echri...@gmail.com, kli...@google.com,
lloz...@chromium.org, llvm-bugs@lists.llvm.org,
natechancel...@gmail.com, srhi...@google.com
>From https://lkml.org/lkml/2018/10/23/136.
The linux kernel as of 4.20 for x86_64 uses the flag `-Wa,-` with `-pipe`.
This causes the use of `no-integrated-as` to hang the build. I *think* `-pipe`
is a red herring.
ie.
$ clang hello_world.c -no-integrated-as -Wa,-
can reproduce the issue. strace'ing with and without -Wa,-, I see:
with -Wa,-:
...
access("/usr/bin/as", F_OK) = 0
...
wait4(167173,
w/o: -Wa,-:
access("/usr/bin/as", F_OK) = 0
...
wait4(167996, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 167996
...
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=167996,
si_uid=366559, si_status=0, si_utime=0, si_stime=1} ---
so however clang is invoking the non-integrated-as, it's not receiving SIGCHLD
in order to exit the `wait4`.
Looking at
$ strace gcc hello_world.c -Wa,-
--
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 38990] llvm-dwarfdump doesn't apply Split DWARF cu_index for debug_loc.dwo
https://bugs.llvm.org/show_bug.cgi?id=38990 Wolfgang Pieb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Wolfgang Pieb --- Fixed with r344807. -- 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 39389] clang-format removes trailing whitespace before assignments in operator= overloads with trailing comments
https://bugs.llvm.org/show_bug.cgi?id=39389 Eugene Zelenko changed: What|Removed |Added Component|clang-tidy |Formatter Product|clang-tools-extra |clang CC||eugene.zele...@gmail.com, ||llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39409] New: fixit should follow symlinks when writing files
https://bugs.llvm.org/show_bug.cgi?id=39409
Bug ID: 39409
Summary: fixit should follow symlinks when writing files
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: mblythes...@gmail.com
CC: llvm-bugs@lists.llvm.org
---
Test input:
---
--
foo_real.cc:
--
#include "foo.h"
void foo( cFoo x){
(void)x;
}
--
foo_real.h:
--
#include "bar.h"
namespace nFoo{
class cFoo{};
class cFooBar: public cBar {};
}
--
bar.h:
--
namespace nBar{
class cBar{};
}
--
foo.cc is a softlink/symlink to foo_real.cc
foo.h is a softlink/symlink to foo_real.h
--
$ ls -o
total 4
-rw-rw-r-- 1 mblythe 34 Oct 23 12:59 bar.h
lrwxrwxrwx 1 mblythe 11 Oct 23 13:02 foo.cc -> foo_real.cc
lrwxrwxrwx 1 mblythe 10 Oct 23 13:02 foo.h -> foo_real.h
-rw-rw-r-- 1 mblythe 50 Oct 23 12:57 foo_real.cc
-rw-rw-r-- 1 mblythe 85 Oct 23 12:59 foo_real.h
--
Compile command and ouptut:
--
$ clang -c -o foo foo.cc -Xclang -fixit
In file included from foo.cc:1:
./foo.h:5:25: error: unknown class name 'cBar'; did you mean 'nBar::cBar'?
class cFooBar: public cBar {};
^~~~
nBar::cBar
./foo.h:5:25: note: FIX-IT applied suggested code changes
./bar.h:2:9: note: 'nBar::cBar' declared here
class cBar{};
^
foo.cc:3:11: error: unknown type name 'cFoo'; did you mean 'nFoo::cFoo'?
void foo( cFoo x){
^~~~
nFoo::cFoo
foo.cc:3:11: note: FIX-IT applied suggested code changes
./foo.h:4:9: note: 'nFoo::cFoo' declared here
class cFoo{};
^
2 errors generated.
--
Expected Result:
--
The softlinks/symlinks remain unchanged, and the fixit changes are applied to
the files that they reference.
--
foo_real.cc:
--
#include "foo.h"
void foo( nFoo::cFoo x){
(void)x;
}
--
foo_real.h:
--
#include "bar.h"
namespace nFoo{
class cFoo{};
class cFooBar: public nBar::cBar {};
}
--
-
Current Incorrect Result:
-
The softlinks/symlinks are replaced with files containing the fixes:
--
$ ls -o
total 8
-rw-rw-r-- 1 mblythe 34 Oct 23 12:59 bar.h
-rw-rw-r-- 1 mblythe 56 Oct 23 13:20 foo.cc
-rw-rw-r-- 1 mblythe 91 Oct 23 13:20 foo.h
-rw-rw-r-- 1 mblythe 50 Oct 23 12:57 foo_real.cc
-rw-rw-r-- 1 mblythe 85 Oct 23 12:59 foo_real.h
--
I realize that it may be an uncommon or unusual use case to have the source
files be softlinks/symlinks, but I'd expect it to be well-supported.
--
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 37953] [meta] [debugify] fix -check-debugify failures
https://bugs.llvm.org/show_bug.cgi?id=37953 Bug 37953 depends on bug 37959, which changed state. Bug 37959 Summary: [debugify] globalopt fail https://bugs.llvm.org/show_bug.cgi?id=37959 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 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS
https://bugs.llvm.org/show_bug.cgi?id=32146 Bug 32146 depends on bug 38150, which changed state. Bug 38150 Summary: X86InstrInfo::analyzeBranch doesn't preserve undef/kill flags on $eflags https://bugs.llvm.org/show_bug.cgi?id=38150 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 37959] [debugify] globalopt fail
https://bugs.llvm.org/show_bug.cgi?id=37959 Jordan Rupprecht 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 38150] X86InstrInfo::analyzeBranch doesn't preserve undef/kill flags on $eflags
https://bugs.llvm.org/show_bug.cgi?id=38150 Francis Visoiu Mistrih changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||franci...@yahoo.com, ||ma...@braunis.de Fixed By Commit(s)||r344970 --- Comment #1 from Francis Visoiu Mistrih --- Matthias fixed this in r344970. -- 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 39408] New: Documentation on recommended workflows
https://bugs.llvm.org/show_bug.cgi?id=39408 Bug ID: 39408 Summary: Documentation on recommended workflows Product: Documentation Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: greg.bedw...@sony.com, llvm-bugs@lists.llvm.org, ztur...@google.com On the llvm-dev discussion about supporting building with Visual Studio: https://lists.llvm.org/pipermail/llvm-dev/2018-October/126778.html Zachary suggested alternate VS/VSCode + Ninja workflows, but we don't do much to document these: https://llvm.org/docs/GettingStarted.html https://clang.llvm.org/get_started.html We have "Using Ninja alongside Visual Studio" but it doesn't explain the exact procedures involved, especially for day2day development, debugging etc. Nor do we mention the builtin VS CMake support etc. It'd be really good if we could document such workflows better (VS/VSCode, Ninja etc.) so that they are more obvious/attractive to developers. -- 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 39407] New: llvm-objdump: add support for '--reloc' as an alias of -r
https://bugs.llvm.org/show_bug.cgi?id=39407 Bug ID: 39407 Summary: llvm-objdump: add support for '--reloc' as an alias of -r Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org The --reloc option in GNU objdump is an alias of the -r option. We should add support for this alias, to make it easier for people to transition from GNU objdump to llvm-objdump. -- 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 39406] New: llvm-objdump: add support for '--syms' as an alias of -t
https://bugs.llvm.org/show_bug.cgi?id=39406 Bug ID: 39406 Summary: llvm-objdump: add support for '--syms' as an alias of -t Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org The --syms option in GNU objdump is an alias of the -t option. We should add support for this alias, to make it easier for people to transition from GNU objdump to llvm-objdump. -- 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 39405] New: JSON parser in LLDB does not accept []
https://bugs.llvm.org/show_bug.cgi?id=39405 Bug ID: 39405 Summary: JSON parser in LLDB does not accept [] Product: lldb Version: unspecified Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: david.bolvan...@gmail.com CC: llvm-bugs@lists.llvm.org Internal JSON parser in LLDB does not accept valid “[]”. Maybe is it worth to do some refactoring and use JSON lib from LLVM in LLDB? -- 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 39404] New: llvm-objdump: add support for '--full-contents' as an alias for -s
https://bugs.llvm.org/show_bug.cgi?id=39404 Bug ID: 39404 Summary: llvm-objdump: add support for '--full-contents' as an alias for -s Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org In GNU objdump, the -s option has an alias "--full-contents". llvm-objdump should provide this same alias so that users can easily transition from GNU to llvm tools. -- 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 39403] New: llvm-size: Reject unknown radix values
https://bugs.llvm.org/show_bug.cgi?id=39403 Bug ID: 39403 Summary: llvm-size: Reject unknown radix values Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-size Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org The --radix switch does not behave well when the radix value is an unknown (i.e. not 8/10/16) value: C:\Work>llvm-size.exe bar.elf textdata bss dec hex filename 58 204 0 262 106 bar.elf C:\Work>llvm-size.exe bar.elf --radix=2 textdata bss dec hex filename 262 106 bar.elf GNU size produces the error message "Invalid radix: 2" in the second case. We should do the same, or something similar. -- 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 39402] New: Don't crash when using -a on non-archives
https://bugs.llvm.org/show_bug.cgi?id=39402
Bug ID: 39402
Summary: Don't crash when using -a on non-archives
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: llvm-objdump
Assignee: unassignedb...@nondot.org
Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
-a prints archive headers. It should probably emit a warning/error and not do
anything when specified for a regular object file. However, it instead crashes,
because it attempts to dereference a null pointer:
static void DumpObject(ObjectFile *o, const Archive *a = nullptr,
const Archive::Child *c = nullptr) {
...
if (ArchiveHeaders && !MachOOpt)
printArchiveChild(a->getFileName(), *c); // a will be null here
...
}
--
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] Issue 11064 in oss-fuzz: llvm: Build failure
Comment #1 on issue 11064 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11064#c1 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-19b2142c-ef11-46e0-b689-383de47631ab.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39400] New: stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs 'int')
https://bugs.llvm.org/show_bug.cgi?id=39400
Bug ID: 39400
Summary: stdint.h:228:25: error: typedef redefinition with
different types ('int16_t' (aka 'short') vs 'int')
Product: clang
Version: 6.0
Hardware: All
OS: Solaris
Status: NEW
Severity: normal
Priority: P
Component: Headers
Assignee: unassignedclangb...@nondot.org
Reporter: petr.sumb...@oracle.com
CC: llvm-bugs@lists.llvm.org
$ clang --version
Oracle Solaris clang version 3.8.1 (tags/RELEASE_381/final) (based on LLVM
3.8.1)
Target: x86_64-pc-solaris2.11
Thread model: posix
InstalledDir: /usr/bin
$ cat test.c
#include
#include
$ clang -ffreestanding -c test.c
In file included from test.c:2:
/usr/lib/amd64/clang/6.0.1/include/stdint.h:228:25: error: typedef redefinition
with different types ('int16_t' (aka 'short') vs 'int')
typedef __int_least16_t int_fast16_t;
^
/usr/include/sys/int_types.h:116:15: note: previous definition is here
typedef int int_fast16_t;
^
In file included from test.c:2:
/usr/lib/amd64/clang/6.0.1/include/stdint.h:229:26: error: typedef redefinition
with different types ('uint16_t' (aka 'unsigned short') vs 'unsigned int')
typedef __uint_least16_t uint_fast16_t;
^
/usr/include/sys/int_types.h:127:23: note: previous definition is here
typedef unsigned intuint_fast16_t;
^
In file included from test.c:2:
/usr/lib/amd64/clang/6.0.1/include/stdint.h:235:23: error: typedef redefinition
with different types ('signed char' vs 'char')
typedef __INT8_TYPE__ int8_t;
^
/usr/include/sys/int_types.h:51:16: note: previous definition is here
typedef charint8_t;
^
3 errors 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 39399] New: Update patch submission guidelines
https://bugs.llvm.org/show_bug.cgi?id=39399 Bug ID: 39399 Summary: Update patch submission guidelines Product: Website Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Documentation Assignee: unassignedb...@nondot.org Reporter: samuel.thiba...@ens-lyon.org CC: llvm-bugs@lists.llvm.org Hello, http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch says "Once your patch is ready, submit it by emailing it to the appropriate project’s commit mailing list". But from the traffic on llvm-commit, it seems that phabricator is largely preferred nowadays, and a patch sent to the mailing list will get lost. That page should thus probably rather point at http://llvm.org/docs/Phabricator.html nowadays. -- 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 39398] New: [DAG] Assertion `N->getOpcode() != ISD::DELETED_NODE && "Deleted Node added to Worklist"' failed.
https://bugs.llvm.org/show_bug.cgi?id=39398
Bug ID: 39398
Summary: [DAG] Assertion `N->getOpcode() != ISD::DELETED_NODE
&& "Deleted Node added to Worklist"' failed.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: max.kazant...@azul.com
CC: llvm-bugs@lists.llvm.org
The following test fails when llc runs on it:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1"
define void @pluto(i8* %arg, float* %arg1) #0 {
bb:
%tmp = getelementptr inbounds i8, i8* %arg, i64 72
%tmp2 = bitcast i8* %tmp to float*
%tmp3 = load float, float* %tmp2, align 4
%tmp4 = load float, float* %arg1
%tmp5 = fadd float %tmp4, 0.00e+00
%tmp6 = fcmp ogt float %tmp5, 0.00e+00
%tmp7 = select i1 %tmp6, i64 9223372036854775807, i64 -9223372036854775808
%tmp8 = insertelement <4 x i64> undef, i64 %tmp7, i32 0
%tmp9 = shufflevector <4 x i64> %tmp8, <4 x i64> undef, <4 x i32>
zeroinitializer
br label %bb10
bb10: ; preds = %bb10, %bb
%tmp11 = phi i32 [ 0, %bb ], [ %tmp30, %bb10 ]
%tmp12 = phi <4 x i32> [ , %bb ], [ %tmp31, %bb10
]
%tmp13 = phi <4 x i64> [ zeroinitializer, %bb ], [ %tmp28, %bb10 ]
%tmp14 = phi <4 x i64> [ zeroinitializer, %bb ], [ %tmp29, %bb10 ]
%tmp15 = phi <4 x i32> [ , %bb ], [ %tmp32, %bb10
]
%tmp16 = add <4 x i32> %tmp12,
%tmp17 = add <4 x i32> %tmp15,
%tmp18 = zext <4 x i32> %tmp12 to <4 x i64>
%tmp19 = zext <4 x i32> %tmp16 to <4 x i64>
%tmp20 = xor <4 x i64> %tmp18,
%tmp21 = xor <4 x i64> %tmp19,
%tmp22 = icmp ugt <4 x i32> %tmp15,
%tmp23 = icmp ugt <4 x i32> %tmp17,
%tmp24 = mul <4 x i64> %tmp9, %tmp20
%tmp25 = mul <4 x i64> %tmp9, %tmp21
%tmp26 = select <4 x i1> %tmp22, <4 x i64> zeroinitializer, <4 x i64> %tmp24
%tmp27 = select <4 x i1> %tmp23, <4 x i64> zeroinitializer, <4 x i64> %tmp25
%tmp28 = add <4 x i64> %tmp13, %tmp26
%tmp29 = add <4 x i64> %tmp14, %tmp27
%tmp30 = add i32 %tmp11, 8
%tmp31 = add <4 x i32> %tmp12,
%tmp32 = add <4 x i32> %tmp15,
%tmp33 = icmp eq i32 %tmp30, 232
br i1 %tmp33, label %bb34, label %bb10
bb34: ; preds = %bb10
%tmp35 = add <4 x i64> %tmp29, %tmp28
%tmp36 = shufflevector <4 x i64> %tmp35, <4 x i64> undef, <4 x i32>
%tmp37 = add <4 x i64> %tmp35, %tmp36
%tmp38 = shufflevector <4 x i64> %tmp37, <4 x i64> undef, <4 x i32>
%tmp39 = add <4 x i64> %tmp37, %tmp38
%tmp40 = extractelement <4 x i64> %tmp39, i32 0
%tmp41 = trunc i64 %tmp40 to i32
%tmp42 = sitofp i32 %tmp41 to float
%tmp43 = fsub float %tmp3, %tmp42
store float %tmp43, float* %arg1, align 4
ret void
}
The failure looks like this:
llc: /home/mkazantsev/work/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:178:
void {anonymous}::DAGCombiner::AddToWorklist(llvm::SDNode*): Assertion
`N->getOpcode() != ISD::DELETED_NODE && "Deleted Node added to Worklist"'
failed.
Stack dump:
0. Program arguments: /home/mkazantsev/work/llvm/build/buildRA/bin/llc
./test.ll
1. Running pass 'Function Pass Manager' on module './test.ll'.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@pluto'
#0 0x7f560b939d2a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/mkazantsev/work/llvm/lib/Support/Unix/Signals.inc:499:0
#1 0x7f560b9382ba llvm::sys::RunSignalHandlers()
/home/mkazantsev/work/llvm/lib/Support/Signals.cpp:67:0
#2 0x7f560b9383f5 SignalHandler(int)
/home/mkazantsev/work/llvm/lib/Support/Unix/Signals.inc:358:0
#3 0x7f560ac11390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f5609fca428 gsignal
/build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f5609fcc02a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0
#6 0x7f5609fc2bd7 __assert_fail_base
/build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0
#7 0x7f5609fc2c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x7f560b6ff43c llvm::SmallVectorTemplateBase<(anonymous
namespace)::DAGCombiner::MemOpLink, false>::grow(unsigned long)
(.constprop.774)
/home/mkazantsev/work/llvm/include/llvm/ADT/SmallVector.h:240:0
#9 0x7f560be46b31 LookupBucketFor
/home/mkazantsev/work/llvm/include/llvm/ADT/DenseMap.h:592:0
#10 0x7f560be46b31 LookupBucketFor
/home/mkazantsev/work/llvm/include/llvm/ADT/DenseMap.h:632:0
#11 0x7f560be46b31 try_emplace
/home/mkazantsev/work/llvm/include/llvm/ADT/DenseMap.h:213:0
#12 0x7f560be46b31 llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::SDNode*,
unsigned int, llvm::DenseMapInfo,
llvm::detail::DenseMapPair
>::insert(std::pair&&)
/home/mkazantsev/work/llvm/include/llvm/ADT/DenseMap.h:204:0
#13 0x7f560be46b31 AddToWorklist
[llvm-bugs] [Bug 38254] Unable to output assembly for x86_64 mingw after "Fix GCC ABI compatibility for comdat things"
https://bugs.llvm.org/show_bug.cgi?id=38254 Martin Storsjö changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Storsjö --- Marking this as resolved, as I had forgotten to do previously. -- 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 39397] New: Make SVN to monorepo mirror more robust
https://bugs.llvm.org/show_bug.cgi?id=39397 Bug ID: 39397 Summary: Make SVN to monorepo mirror more robust Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: jykni...@google.com, llvm-bugs@lists.llvm.org, m...@sqlby.me Blocks: 39393 Improve the mirroring from SVN->monorepo to minimize downtime caused by: - Committing with an email that is not in the email map. - Adding files to locations that aren't expected. - Hosting outages or hardware issues. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39393 [Bug 39393] [meta] Tasks related to hosting source code at GitHub -- 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 39396] New: Work with GitHub to fix SVN read-only access
https://bugs.llvm.org/show_bug.cgi?id=39396 Bug ID: 39396 Summary: Work with GitHub to fix SVN read-only access Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: ASSIGNED Severity: enhancement Priority: P Component: new bugs Assignee: an...@korobeynikov.info Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org Blocks: 39393 Anton, do you have a link to the GitHub issue you filed for this? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39393 [Bug 39393] [meta] Tasks related to hosting source code at GitHub -- 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 39395] New: Update GitHubMove.rst to reflect finalized monorepo layout
https://bugs.llvm.org/show_bug.cgi?id=39395 Bug ID: 39395 Summary: Update GitHubMove.rst to reflect finalized monorepo layout Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org Blocks: 39393 Also remove proposed layouts to prevent confusion. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39393 [Bug 39393] [meta] Tasks related to hosting source code at GitHub -- 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
