[llvm-bugs] [Bug 39718] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu: fatal error: error in backend: Broken function found, compilation aborted!
https://bugs.llvm.org/show_bug.cgi?id=39718
Bug ID: 39718
Summary: clang crashes on valid code at -Os and above on
x86_64-linux-gnu: fatal error: error in backend:
Broken function found, compilation aborted!
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Tested with trunk revision 347212.
$ clangpolly -v
clang version 8.0.0 (http://llvm.org/git/clang.git
8ab54153b8c32d61c5c2251ae490940cbe47a6cc) (http://llvm.org/git/llvm.git
23ff23942df1b56bc58b0282ec762f2aa62c7406)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/su/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clangpolly -O1 small.c; ./a.out
$
$ clangpolly -Os small.c
Instruction does not dominate all uses!
%spec.select = zext i1 %not.tobool2 to i8
%and = and i8 %0, %spec.select
in function main
fatal error: error in backend: Broken function found, compilation aborted!
clang-6: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 8.0.0 (http://llvm.org/git/clang.git
8ab54153b8c32d61c5c2251ae490940cbe47a6cc) (http://llvm.org/git/llvm.git
23ff23942df1b56bc58b0282ec762f2aa62c7406)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/su/bin
clang-6: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-6: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-6: note: diagnostic msg: /tmp/small-8cd6d5.c
clang-6: note: diagnostic msg: /tmp/small-8cd6d5.sh
clang-6: note: diagnostic msg:
$
char a, e, f;
int b, c, d;
char g (char h)
{
return h == 0 ? a : a % h;
}
int main ()
{
for (; d; d++)
b = g (e & (f && (c = 1)));
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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39584, which changed state. Bug 39584 Summary: Merge r345353 into the 7.0 branch : Teach the DominatorTree fallback to recalculation when applying updates to speedup JT (PR37929) https://bugs.llvm.org/show_bug.cgi?id=39584 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 19463] VLAIS - false positive
https://bugs.llvm.org/show_bug.cgi?id=19463 Nick Desaulniers changed: What|Removed |Added Status|NEW |RESOLVED CC||ndesaulni...@google.com Resolution|--- |INVALID --- Comment #6 from Nick Desaulniers --- > unsigned long mask[(((num_processors) + (8 * sizeof(long)) - 1) / (8 * > sizeof(long)))]; > I totally agree this looks and smells like VLAIS, but is it? num_processors is not an ICE. As pointed out in comment #2. I removed this from the kernel anyway as pointed out in comment #5. Closing as invalid. -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39708, which changed state. Bug 39708 Summary: Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std' https://bugs.llvm.org/show_bug.cgi?id=39708 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 39708] Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'
https://bugs.llvm.org/show_bug.cgi?id=39708 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|r341697 |r341697 r347276 Resolution|--- |FIXED --- Comment #2 from Tom Stellard --- Merged: r347276 -- 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 39716] New: [DebugInfo] Unused arguments aren't visible in optimized code.
https://bugs.llvm.org/show_bug.cgi?id=39716
Bug ID: 39716
Summary: [DebugInfo] Unused arguments aren't visible in
optimized code.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: apra...@apple.com, fr...@apple.com,
jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org, r...@google.com,
v...@vedantk.com, v...@apple.com, ztur...@google.com
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x00010f84 a.out`fn2(a=, b=,
c=) at optout.c:12:10 [opt]
9fn2 (long int a, long int b, long int c)
10 {
11 long int q = 2 * a;
-> 12 return fn1 (5, 6, 7);
13 }
14
15 int main(void) {
(lldb) frame var
(long) a =
(long) b =
(long) c =
(long) q =
A gcc-built binary debugged with gdb yields:
Breakpoint 1, main () at opt.c:16
16 return fn2(14, 23, 34);
(gdb) s
fn2 (c=34, b=23, a=14) at opt.c:12
12 return fn1 (5, 6, 7);
(gdb) info args
c = 34
b = 23
a = 14
Testcase:
__attribute__((noinline))
int fn1 (long int x, long int y, long int z) {
int l = x * 2;
int q = y * z;
return l + q;
}
__attribute__((noinline)) long int
fn2 (long int a, long int b, long int c)
{
long int q = 2 * a;
return fn1 (5, 6, 7);
}
int main(void) {
return fn2(14, 23, 34);
}
--
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 39715] New: [DebugInfo] Lifetime of function arguments is too short in optimized code.
https://bugs.llvm.org/show_bug.cgi?id=39715
Bug ID: 39715
Summary: [DebugInfo] Lifetime of function arguments is too
short in optimized code.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: apra...@apple.com, fr...@apple.com,
jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org, r...@google.com,
v...@vedantk.com, v...@apple.com, ztur...@google.com
Same test case as before:
__attribute__((noinline))
int fn1 (long int x, long int y, long int z) {
int l = x * 2;
int q = y * z;
return l + q;
}
__attribute__((noinline)) long int
fn2 (long int a, long int b, long int c)
{
long int q = 2 * a;
return fn1 (5, 6, 7);
}
int main(void) {
return fn2(14, 23, 34);
}
(built with -O3 -g).
lldb session:
Process 30254 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x00010f74 a.out`fn1(x=5, y=6, z=7) at optout.c:4:19
[opt]
1__attribute__((noinline))
2int fn1 (long int x, long int y, long int z) {
3int l = x * 2;
-> 4int q = y * z;
5return l + q;
6}
7
(lldb) frame var z
(long) z = 7
(lldb) n
Process 30254 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x00010f77 a.out`fn1(x=5, y=6, z=) at
optout.c:5:18 [opt]
2int fn1 (long int x, long int y, long int z) {
3int l = x * 2;
4int q = y * z;
-> 5return l + q;
6}
7
8__attribute__((noinline)) long int
(lldb) frame var z
(long) z =
--
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 18896] Linux kernel ARM: Compiled successfully but final report not generated.
https://bugs.llvm.org/show_bug.cgi?id=18896 Nick Desaulniers changed: What|Removed |Added Resolution|--- |INVALID CC||ndesaulni...@google.com Status|NEW |RESOLVED --- Comment #3 from Nick Desaulniers --- Please try again compiling with Clang and reopen if you can still reproduce. -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 18896, which changed state. Bug 18896 Summary: Linux kernel ARM: Compiled successfully but final report not generated. https://bugs.llvm.org/show_bug.cgi?id=18896 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 11326, which changed state. Bug 11326 Summary: Clang generates incorrect code for structure member offsets on ARM https://bugs.llvm.org/show_bug.cgi?id=11326 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- 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 11326] Clang generates incorrect code for structure member offsets on ARM
https://bugs.llvm.org/show_bug.cgi?id=11326 Nick Desaulniers changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26899] Valarray constructor should have the elements of the array value-initialized as of C++14 standard, but they are initialized using a copy constructor.
https://bugs.llvm.org/show_bug.cgi?id=26899 hst...@ca.ibm.com changed: What|Removed |Added CC||hst...@ca.ibm.com Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from hst...@ca.ibm.com --- The committee has clarified that the user is responsible for not supplying a type where the difference matters: https://cplusplus.github.io/LWG/lwg-defects.html#2699 -- 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 11461 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: val != Map.end() && "unexpected runtime library name"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-11-19 Type: Bug New issue 11461 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: val != Map.end() && "unexpected runtime library name" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11461 Detailed report: https://oss-fuzz.com/testcase?key=5690233278955520 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--wasm32-O2 Fuzz target binary: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: val != Map.end() && "unexpected runtime library name" llvm::GetLibcallSignature llvm::WebAssemblyMCInstLower::GetExternalSymbolSymbol Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201811180234:201811190234 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5690233278955520 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 39714] New: -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill
https://bugs.llvm.org/show_bug.cgi?id=39714 Bug ID: 39714 Summary: -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill Product: new-bugs Version: 7.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jholaj...@arxan.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21130 --> https://bugs.llvm.org/attachment.cgi?id=21130=edit repro.ll can be use to reproduce the incorrect assembly generated by llc The attached test case demonstrates an issue where lowering armv7 bitcode for iOS using -fast-isel=0 results in a register being reloaded from the stack without first being spilled to the stack. This results in an unknown value being loaded into the register and undefined runtime results. This bug is important because Apple forces use of -fast-isel=0 when re-lowering armv7 bitcode built using Enable Bitcode set to Yes. There is no way to disable use of -fast-isel=0 when submitting bitcode to Apple. Use the following command line with the attached repro.ll: llc -relocation-model=pic -O0 -fast-isel=0 repro.ll -filetype=asm -o repro.s The resultant repro.s will contain the following line: ldr.w r1, [r6, #2500] @ 4-byte Reload The reload of r1 with r6 offset by #2500 was never spilled to the stack. This instruction is reading and unknown value from the stack and populating r1 with it. This leads to undefined runtime behavior. >From the repro.ll file, you can see that a function named printAggregate() is being invoked: call void @printAggregate(%struct.structOfStrings* byval align 4 @structOfStrings2, i32 2) #18 call void @printAggregate(%struct.structOfStrings* byval align 4 @structOfStrings1, i32 1) #18 call void @printAggregate(%struct.structOfStrings* byval align 4 @structOfStrings3, i32 3) #18 In the repro.s file, prior to the first invocation of printAggregate() we can see that the second parameter is populated into r1 via the following instruction: movsr1, #2 This is also the case with the third invocation of printAggregate(): movsr1, #3 It is unclear why the second invocation of printAggregate() does not also use movs, instead trying to Reload r1 from the stack even though it was never spilled. -- 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 39713] New: std::alignment_of::value might be different from alignof(T)
https://bugs.llvm.org/show_bug.cgi?id=39713 Bug ID: 39713 Summary: std::alignment_of::value might be different from alignof(T) Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: sbe...@google.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Simple repro: #include static_assert(alignof(long long) == std::alignment_of::value); With compiler flags: -std=c++17 -m32 -stdlib=libc++ alignof(long long) == 4 std::alignment_of::value == 8 The problem is that std::alignment_of is using __alignof__ which gives a different result than alignof in this particular 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 39712] New: clang-cl generates more static initializers than VC++ does
https://bugs.llvm.org/show_bug.cgi?id=39712
Bug ID: 39712
Summary: clang-cl generates more static initializers than VC++
does
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: brucedaw...@chromium.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This is an example of code that VC++ optimizes better than clang-cl. With VC++
there is no static initializer whereas with clang there is:
struct my_id {
my_id() : v_(0) {}
int v_;
};
template struct Foo {
static my_id id;
};
template my_id Foo::id;
int main() { Foo::id.v_++; }
So, this is a missing optimization in LLVM. LLVM's globalopt pass is supposed
to handle this, but it gives up too easily. The COMDAT scheme that Microsoft
uses is clever and allows the compiler to optimize this to static
initialization without changing the ABI.
This was reported in crbug.com/782027 and it leads to eleven static
initializers in clang-cl builds of Chrome (chrome.exe, chrome.dll, and
chrome_child.dll) that are not present in VC++ builds, coming from the VC++ STL
header files.
--
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 39711] New: Broken PLT in statically linked binary with -z now -z retpolineplt
https://bugs.llvm.org/show_bug.cgi?id=39711
Bug ID: 39711
Summary: Broken PLT in statically linked binary with -z now -z
retpolineplt
Product: lld
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: ema...@freebsd.org
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org
Hello world test code:
% cat hello.c
#include
int main(int argc, char *argv[]) { printf("Hi\n"); }
lld version:
% ld.lld --version
LLD 6.0.1 (FreeBSD 335540-125) (compatible with GNU linkers)
Build test application:
% LLD_REPRODUCE=hello.tar cc -g -static -Wl,-zretpolineplt,-znow hello.c -o
hello.static-retpoline-now
Application segfaults:
% ./hello.static-retpoline-now
zsh: illegal hardware instruction (core dumped) ./hello.static-retpoline-now
We have a PLT entry that jumps to an invalid location:
% objdump -S -section=.plt hello.static-retpoline-now
hello.static-retpoline-now: file format ELF64-x86-64
Disassembly of section .plt:
.plt:
2a0890: 4c 8b 1d a9 5f 00 00movq24489(%rip), %r11
2a0897: e9 d4 ff ff ff jmp -44 <_init+0x8>
2a089c: cc int3
2a089d: cc int3
2a089e: cc int3
2a089f: cc int3
Note that there is a .plt entry here, but no PLT header.
Reproducer: https://people.freebsd.org/~emaste/lld/hello.tar.xz
See also FreeBSD PR 26 https://bugs.freebsd.org/26
--
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 38987] (REGRESSION) crash in coverage build: error in backend: File exit not handled before popRegions
https://bugs.llvm.org/show_bug.cgi?id=38987 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||347261 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 39258] Coverage mapping fails with "File exit not handled before popRegions" on #define'd goto
https://bugs.llvm.org/show_bug.cgi?id=39258 Vedant Kumar changed: What|Removed |Added Fixed By Commit(s)||347262 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 3473] need load/store merging in dag combine
https://bugs.llvm.org/show_bug.cgi?id=3473 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||nir...@google.com --- Comment #3 from Nirav Dave --- This functionality was added some time ago. -- 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 21207] DAG Combiner can generate illegal operations
https://bugs.llvm.org/show_bug.cgi?id=21207 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||347255 Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Legalization on the fly was added some time ago which should avoid this problem. rL347255 makes the op legality testing consistent throughout DAGCombiner::SimplifyNodeWithTwoResults. -- 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 39710] New: Emission of DW_TAG_formal_parameter location is inaccurate on Linux (with -O3)
https://bugs.llvm.org/show_bug.cgi?id=39710
Bug ID: 39710
Summary: Emission of DW_TAG_formal_parameter location is
inaccurate on Linux (with -O3)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: apra...@apple.com, fr...@apple.com,
jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org, r...@google.com,
v...@apple.com
There has been a lot of talking about about unrecoverable function arguments
for optimized builds, so I decided to give it a try to see if there's something
that could be done to improve.
Take the following test case:
__attribute__((noinline))
int fn1 (long int x, long int y, long int z) {
int l = x * 2;
int q = y * z;
return l + q;
}
__attribute__((noinline)) long int
fn2 (long int a, long int b, long int c)
{
long int q = 2 * a;
return fn1 (5, 6, 7);
}
int main(void) {
return fn2(14, 23, 34);
}
Build with -O3 -g. Set a breakpoint on fn1, and try to print the arguments
(e.g. through `frame var`).
You'll realize that you can recover them on a recent MacOS (Mojave), but you
can't on ubuntu 18.10.
I started looking a little bit into why this was the case, to immediately find
out the DWARF emission for the formal parameter differs on the two platforms.
Namely:
MacOS:
0x0043: DW_TAG_formal_parameter
DW_AT_location(0x
[0x00010f70, 0x00010f74): DW_OP_reg5 RDI
[0x00010f74, 0x00010f7c): DW_OP_reg5 RDI)
DW_AT_name("x")
DW_AT_decl_file
("/Users/davide/llvm-monorepo/llvm-mono/build/bin/optout.c")
DW_AT_decl_line (2)
DW_AT_type(0x0104 "long int")
Linux:
0x0043: DW_TAG_formal_parameter
DW_AT_location(0x)
DW_AT_name("x")
DW_AT_decl_file ("/home/davide/optimized_code/./opt.c")
DW_AT_decl_line (2)
DW_AT_type(0x00f1 "long int")
While the former contains a location list pointing at the register where the
debugger should retrieve the argument, the second one contains an empty
location list.
--
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 39709] New: [X86] Suboptimal code in vXi8 vector multiply reduction
https://bugs.llvm.org/show_bug.cgi?id=39709 Bug ID: 39709 Summary: [X86] Suboptimal code in vXi8 vector multiply reduction Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Multiplying vXi8 vectors requires widening elements to 16 bits to use vXi16 pmullw then shrinking back to i8. As of r347240 we use punpacklbw/punpackhbw to do the expansion create undef upper elements and we use an AND+PACKUS to merge the high and low unpacked values back together after the two pmullw. When we're doing a horizontal reduction we end up packing after each step and then unpacking at the start of the next step. It would be great if we could combine these size changes away. Some of the packs and unpacks are separated by shuffles to move elements from higher elements to lower elements to do the reduction. We should see if we can handle widening those element movement shuffles as well. These things can be seen in vector-reduce-mul.ll -- 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 8564] [patch] On Mac OS libLLVM-2.9svn.dylib is linked to be used by tools only
https://bugs.llvm.org/show_bug.cgi?id=8564 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED CC||r...@google.com Status|NEW |RESOLVED --- Comment #2 from Reid Kleckner --- We've replaced the autoconf build system since this was filed. Please reopen the bug if you are still affected. -- 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 4370] Debug/Function.o is 700k
https://bugs.llvm.org/show_bug.cgi?id=4370 Reid Kleckner changed: What|Removed |Added Component|System Library |Core LLVM classes Resolution|--- |FIXED Status|NEW |RESOLVED CC||r...@google.com --- Comment #5 from Reid Kleckner --- I think I fixed the real problem this is referring to back in r258774, which replaced the radix-y string prefix generated switch code with a plain binary search. My build (clang-cl, optimizations enabled, debug info enabled, asserts enabled) has a Function.obj that's 2.9MB, so that's quite large relative to these numbers, but the text is very very small, only 38618 bytes. The readonly data is about 500KB, i.e. the tables of intrinsic data. The rest is debug info. I don't think there's anything to do here. We need the intrinsic data tables somewhere. -- 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 12743] PathV2: unique_file("dir%%/file") doesn't create unique directory "dir%%"
https://bugs.llvm.org/show_bug.cgi?id=12743 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||r...@google.com --- Comment #4 from Reid Kleckner --- > This appears to be resolved already, does it not? Marking 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 39708] New: Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'
https://bugs.llvm.org/show_bug.cgi?id=39708 Bug ID: 39708 Summary: Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std' Product: new-bugs Version: 7.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 39106 Is it OK to merge the following revision(s) to the 7.0 branch? 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 10314] "bitset::operator[](size_t) const" does not return bool
https://bugs.llvm.org/show_bug.cgi?id=10314 hst...@ca.ibm.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||hst...@ca.ibm.com --- Comment #6 from hst...@ca.ibm.com --- This still fails with trunk: https://wandbox.org/permlink/HnDDdwYxfyfivRbz I am not saying that the proxy type should go, but the problem report should not read 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 39707] New: Wrong condition evaluation
https://bugs.llvm.org/show_bug.cgi?id=39707
Bug ID: 39707
Summary: Wrong condition evaluation
Product: libraries
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: roy...@freebsd.org
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Hello,
While compiling Xen with clang version 6.0.1 (tags/RELEASE_601/final 335540)
(based on LLVM 6.0.1) on amd64 I came across the following bug. Given this C
code:
static void init_heap_pages(
struct page_info *pg, unsigned long nr_pages)
{
unsigned long i;
bool idle_scrub = false;
/*
* Some pages may not go through the boot allocator (e.g reserved
* memory at boot but released just after --- kernel, initramfs,
* etc.).
* Update first_valid_mfn to ensure those regions are covered.
*/
spin_lock(_lock);
first_valid_mfn = mfn_min(page_to_mfn(pg), first_valid_mfn);
spin_unlock(_lock);
if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE )
idle_scrub = true;
for ( i = 0; i < nr_pages; i++ )
{
unsigned int nid = phys_to_nid(page_to_maddr(pg+i));
if ( unlikely(!avail[nid]) )
{
unsigned long s = mfn_x(page_to_mfn(pg + i));
unsigned long e = mfn_x(mfn_add(page_to_mfn(pg + nr_pages - 1),
1));
bool_t use_tail = (nid == phys_to_nid(pfn_to_paddr(e - 1))) &&
!(s & ((1UL << MAX_ORDER) - 1)) &&
(find_first_set_bit(e) <= find_first_set_bit(s));
unsigned long n;
n = init_node_heap(nid, mfn_x(page_to_mfn(pg + i)), nr_pages - i,
_tail);
BUG_ON(i + n > nr_pages);
if ( n && !use_tail )
{
i += n - 1;
continue;
}
if ( i + n == nr_pages )
break;
nr_pages -= n;
}
free_heap_pages(pg + i, 0, scrub_debug || idle_scrub);
}
}
llvm generates the following assembly:
Dump of assembler code for function init_heap_pages:
0x82d080223900 <+0>: push %rbp
0x82d080223901 <+1>: mov%rsp,%rbp
0x82d080223904 <+4>: push %r15
0x82d080223906 <+6>: push %r14
0x82d080223908 <+8>: push %r13
0x82d08022390a <+10>:push %r12
0x82d08022390c <+12>:push %rbx
0x82d08022390d <+13>:sub$0x28,%rsp
0x82d080223911 <+17>:mov%rsi,%r15
0x82d080223914 <+20>:mov%rdi,%rbx
0x82d080223917 <+23>:movabs $0x7d20,%r12
0x82d080223921 <+33>:lea0x267d08(%rip),%r14#
0x82d08048b630
0x82d080223928 <+40>:mov%r14,%rdi
0x82d08022392b <+43>:callq 0x82d08023a4c0 <_spin_lock>
0x82d080223930 <+48>:mov%rbx,-0x40(%rbp)
0x82d080223934 <+52>:lea(%rbx,%r12,1),%rdi
0x82d080223938 <+56>:sar$0x5,%rdi
0x82d08022393c <+60>:callq 0x82d0802249c0
0x82d080223941 <+65>:mov%rax,%rdi
0x82d080223944 <+68>:callq 0x82d080222340 <_mfn>
0x82d080223949 <+73>:mov0x267cd8(%rip),%rsi#
0x82d08048b628
0x82d080223950 <+80>:mov%rax,%rdi
0x82d080223953 <+83>:callq 0x82d080222310
0x82d080223958 <+88>:mov%rax,0x267cc9(%rip)#
0x82d08048b628
0x82d08022395f <+95>:mov%r14,%rdi
0x82d080223962 <+98>:callq 0x82d08023a530 <_spin_unlock>
0x82d080223967 <+103>: cmpl $0x3,0x37b032(%rip)#
0x82d08059e9a0
0x82d08022396e <+110>: setb -0x29(%rbp)
0x82d080223972 <+114>: cmpl $0x2,0x228a8b(%rip)#
0x82d08044c404
0x82d080223979 <+121>: sete %al
0x82d08022397c <+124>: mov%r15,-0x38(%rbp)
0x82d080223980 <+128>: test %r15,%r15
0x82d080223983 <+131>: je 0x82d080223aee
0x82d080223989 <+137>: and%al,-0x29(%rbp)
0x82d08022398c <+140>: xor%r12d,%r12d
0x82d08022398f <+143>: jmpq 0x82d080223a70
0x82d080223994 <+148>: mov-0x38(%rbp),%rax
0x82d080223998 <+152>: shl$0x5,%rax
0x82d08022399c <+156>: add-0x40(%rbp),%rax
0x82d0802239a0 <+160>: movabs $0x7d20,%rcx
0x82d0802239aa <+170>: lea(%rcx,%rax,1),%rdi
0x82d0802239ae <+174>: add$0xffe0,%rdi
0x82d0802239b2 <+178>: sar$0x5,%rdi
0x82d0802239b6 <+182>: callq 0x82d0802249c0
0x82d0802239bb <+187>: mov%rax,%rdi
0x82d0802239be <+190>: callq
[llvm-bugs] [Bug 39391] Regression(r342175): ran out of registers during register allocation
https://bugs.llvm.org/show_bug.cgi?id=39391 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Nirav Dave --- It's still possible for the register allocator to get an input that causes it to run out of registers, but this particular case is fixed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10075 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E
Updates: Labels: Deadline-Approaching Comment #2 on issue 10075 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10075#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 39706] New: clang-format gets confused when enum values comma separators are preceded with comments
https://bugs.llvm.org/show_bug.cgi?id=39706
Bug ID: 39706
Summary: clang-format gets confused when enum values comma
separators are preceded with comments
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: eh...@mozilla.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
See the test case below:
$ cat test.cpp
enum foo {
x // comment
, y // comment
, z // comment
};
$ clang-format -style=Google test.cpp
enum foo {
x // comment
,
y // comment
,
z // comment
};
--
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 38391] __llvm_retpoline_r11 has machine verifier errors
https://bugs.llvm.org/show_bug.cgi?id=38391 Francis Visoiu Mistrih changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r345426 Status|NEW |RESOLVED --- Comment #3 from Francis Visoiu Mistrih --- You're right, this is fixed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS
https://bugs.llvm.org/show_bug.cgi?id=32146 Bug 32146 depends on bug 38391, which changed state. Bug 38391 Summary: __llvm_retpoline_r11 has machine verifier errors https://bugs.llvm.org/show_bug.cgi?id=38391 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 27481] X86 make check has a bunch of machine verifier errors
https://bugs.llvm.org/show_bug.cgi?id=27481 Bug 27481 depends on bug 38391, which changed state. Bug 38391 Summary: __llvm_retpoline_r11 has machine verifier errors https://bugs.llvm.org/show_bug.cgi?id=38391 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] Issue 7742 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 7742 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7742#c6 ClusterFuzz testcase 4837581448544256 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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] Issue 7742 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart
Comment #5 on issue 7742 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7742#c5 ClusterFuzz has detected this issue as fixed in range 201811180234:201811190234. Detailed report: https://oss-fuzz.com/testcase?key=4837581448544256 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--wasm32-O2 Fuzz target binary: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart llvm::AsmPrinter::EmitFunctionBody llvm::WebAssemblyAsmPrinter::runOnMachineFunction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201804120529:201804130530 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201811180234:201811190234 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4837581448544256 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #14 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c14 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-c17007a9-1b09-4ea1-9a9f-55102fbf05ae.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 39705] New: Multiline doc comments in enums are copied to following variants
https://bugs.llvm.org/show_bug.cgi?id=39705
Bug ID: 39705
Summary: Multiline doc comments in enums are copied to
following variants
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: emi...@crisal.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
For the following file:
enum Test {
/**
* hello world
*/
A,
B,
C,
}
All the cursors for the enum variants have the same doc comment, which seems
wrong.
This causes https://github.com/rust-lang-nursery/rust-bindgen/issues/1442.
--
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
