[llvm-bugs] [Bug 34115] New: Fix LLVM_OCAML_OUT_OF_TREE
https://bugs.llvm.org/show_bug.cgi?id=34115 Bug ID: 34115 Summary: Fix LLVM_OCAML_OUT_OF_TREE Product: Build scripts Version: trunk Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: jp.depl...@gmail.com CC: llvm-bugs@lists.llvm.org, mgo...@gentoo.org, whitequ...@whitequark.org Created attachment 18944 --> https://bugs.llvm.org/attachment.cgi?id=18944&action=edit The fix If OCaml is not installed in the same tree as LLVM (e.g. with OPAM), the build script doesn't work. Moreover, if SHARED_LIBS is enabled, the resulting binding won't be dynamically linked. Here is a patch that tries to fix these two issues. The patch also fixes the build instructions. I also tried to allow both static and shared libraries if possible (see OPAM package) but my level of comprehension of CMake is quite limited so I gave up. But if anybody have any idea how to do that better, please feel free to discuss this matter 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] [Bug 33954] Performance regression with r308142
https://bugs.llvm.org/show_bug.cgi?id=33954 Amjad Aboud changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Amjad Aboud --- Fix was committed to https://reviews.llvm.org/rL310352. -- 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 34117] New: Merge r310250 to 5.0
https://bugs.llvm.org/show_bug.cgi?id=34117 Bug ID: 34117 Summary: Merge r310250 to 5.0 Product: new-bugs Version: 5.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: simon.dar...@imgtec.com CC: llvm-bugs@lists.llvm.org Please merge r310250 to 5.0, it affects llvm-objdump on native mips32 systems. -- 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 34118] New: Merge r310253+r310267 to 5.0
https://bugs.llvm.org/show_bug.cgi?id=34118 Bug ID: 34118 Summary: Merge r310253+r310267 to 5.0 Product: new-bugs Version: 5.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: simon.dar...@imgtec.com CC: llvm-bugs@lists.llvm.org Please merge r310253+ followup r310267 to 5.0, another bug affecting output on native mips systems. -- 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 34120] New: -Wshadow false-negative compared to gcc
https://bugs.llvm.org/show_bug.cgi?id=34120
Bug ID: 34120
Summary: -Wshadow false-negative compared to gcc
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
class A {
int B;
};
class C : A {
void D(int B) {}
};
$ clang++-6.0 -Wshadow -c wshadow.cpp
$ clang++-5.0 -Wshadow -c wshadow.cpp
$ clang++-4.0 -Wshadow -c wshadow.cpp
$ clang++-3.9 -Wshadow -c wshadow.cpp
$ g++-7 -Wshadow -c wshadow.cpp
wshadow.cpp: In member function ‘void C::D(int)’:
wshadow.cpp:5:17: warning: declaration of ‘B’ shadows a member of ‘C’
[-Wshadow]
void D(int B) {}
^
wshadow.cpp:2:7: note: shadowed declaration is here
int B;
^
$ g++-6 -Wshadow -c wshadow.cpp
wshadow.cpp: In member function ‘void C::D(int)’:
wshadow.cpp:5:17: warning: declaration of ‘B’ shadows a member of ‘C’
[-Wshadow]
void D(int B) {}
^
wshadow.cpp:2:7: note: shadowed declaration is here
int B;
^
$ g++-5 -Wshadow -c wshadow.cpp
wshadow.cpp: In member function ‘void C::D(int)’:
wshadow.cpp:5:17: warning: declaration of ‘B’ shadows a member of ‘C’
[-Wshadow]
void D(int B) {}
^
wshadow.cpp:2:7: note: shadowed declaration is here
int 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 34103] libc++abi doesn't build with -std=c++17
https://bugs.llvm.org/show_bug.cgi?id=34103 Nico Weber changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #4 from Nico Weber --- Our setup is that we build libc++(abi) ourselves and link it statically. We have a global -std= flag. Something like "if you build libc++abi with -std=c++17, it will only work for c++17+ programs" would be cool for us. Eventually something like that will be needed anyhow. Anyhoo, reopened for either that or Richard's suggestion. -- 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 33796] availability attributes override visibility
https://bugs.llvm.org/show_bug.cgi?id=33796 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Nico Weber --- http://llvm.org/viewvc/llvm-project?rev=310382&view=rev -- 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 34121] New: LLD doesn't version linker script symbol aliases
https://bugs.llvm.org/show_bug.cgi?id=34121
Bug ID: 34121
Summary: LLD doesn't version linker script symbol aliases
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: smee...@fb.com
CC: gri...@accesssoftek.com, llvm-bugs@lists.llvm.org,
rafael.espind...@gmail.com, r...@google.com
% cat sym.c
void f() {}
% cat sym.script
g = f;
VERSION { V1 { global: f; g; local: *; }; }
% clang -fPIC -c sym.c
% ld.lld -shared -o libsym.so sym.o sym.script --no-undefined-version
ld.lld: error: version script assignment of 'V1' to symbol 'g' failed: symbol
not defined
ld.bfd handles this correctly. ld.gold complains about having VERSION in a
linker script, but it works correctly if you pass it a separate version script.
I'll explain my use case, in case it helps with understanding the
motivation/suggesting alternatives. I'm renaming a large number of symbols in a
library (via changing an inline namespace), but I still need to preserve both
the old and new names for a while, for backward compatibility. The old and new
names are both versioned (I'm aware this is a pretty weird way to use symbol
versioning, but there's a long story there). As far as I know, I have three
ways to alias the old names to the new ones:
1. attribute((alias)). This requires the alias to be in the same translation
unit as the symbol being aliased, which isn't practical in my case.
2. Define the aliased functions myself to just call the new names. This works,
but it bloats up the text segment and introduces an extra jump. It also doesn't
work for data symbols.
3. Alias via the linker, using linker scripts or --defsym. This seems like the
ideal solution, but both approaches run into issues.
I have a small and (I think) pretty reasonable patch to make --defsym aliases
work with version scripts, but https://bugs.llvm.org/show_bug.cgi?id=34113
makes that patch pretty useless for now. Linker script aliasing gets the symbol
table names correct, but linker script command processing also happens pretty
late, so getting that to play nice with version scripts might be more involved.
One workaround that I think will be good enough for me for now is to just drop
the local: *; from the version script. The source files are already annotated
with correct visibility annotations, so dropping that shouldn't produce any
unwanted exports. It's not super ideal in general though.
--
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 32311] Incorrect result with -O1 -march=skx
https://bugs.llvm.org/show_bug.cgi?id=32311 Hans Wennborg changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Hans Wennborg --- Thank you very much for testing! Let's close this, then. -- 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 34117] Merge r310250 to 5.0
https://bugs.llvm.org/show_bug.cgi?id=34117 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- r310396. Thanks! -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 34117, which changed state. Bug 34117 Summary: Merge r310250 to 5.0 https://bugs.llvm.org/show_bug.cgi?id=34117 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 34118] Merge r310253+r310267 to 5.0
https://bugs.llvm.org/show_bug.cgi?id=34118 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- r310398. -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 34118, which changed state. Bug 34118 Summary: Merge r310253+r310267 to 5.0 https://bugs.llvm.org/show_bug.cgi?id=34118 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 31974] lld-link fails with "LLVM ERROR: Associative COMDAT symbol 'baz' does not exist." when using LTO
https://bugs.llvm.org/show_bug.cgi?id=31974 Robbert Haarman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Robbert Haarman --- As of r295872 we no longer generate associative comdats for SEH. This avoids the issue, so that code that uses exceptions on Windows can now be compiled and linked with LTO. Since that was the goal, I'll close the bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34055] CINDEX_VERSION_MINOR not incremented after an incompatible change in Index.h
https://bugs.llvm.org/show_bug.cgi?id=34055 Nikolai Bozhenov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Nikolai Bozhenov --- r310359 - trunk r310390 - release_50 -- 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 34122] New: Cannot compile with `-static` when using exceptions with target x86_64-w64-windows-gnu
https://bugs.llvm.org/show_bug.cgi?id=34122 Bug ID: 34122 Summary: Cannot compile with `-static` when using exceptions with target x86_64-w64-windows-gnu Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dario.ost...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18947 --> https://bugs.llvm.org/attachment.cgi?id=18947&action=edit program.cpp When trying to compile `program.cpp` (in attachment) with `-static` for target x86_64-w64-windows-gnu this is what happens: ``` $ x86_64-w64-mingw32-clang++ -o program.exe -pthread -static -v program.cpp clang version 6.0.0 (trunk 310227) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang-6.0" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name program.cpp -static-define -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -dwarf-column-info -debugger-tuning=gdb -nostdsysteminc -nobuiltininc -resource-dir /usr/lib/clang/6.0.0 -isystem /usr/bin/../lib/clang/6.0.0/include -isystem /usr/x86_64-w64-mingw32/include/c++/7.1.1 -isystem /usr/x86_64-w64-mingw32/include/c++/7.1.1/x86_64-w64-mingw32 -isystem /usr/x86_64-w64-mingw32/include -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 132 -pthread -fno-use-cxa-atexit -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/program-26420f.o -x c++ program.cpp clang -cc1 version 6.0.0 based upon LLVM 6.0.0svn-r310227 default target x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/clang/6.0.0/include /usr/x86_64-w64-mingw32/include/c++/7.1.1 /usr/x86_64-w64-mingw32/include/c++/7.1.1/x86_64-w64-mingw32 /usr/x86_64-w64-mingw32/include End of search list. "/usr/bin/x86_64-w64-mingw32-ld" -m i386pep -Bstatic -o program.exe /usr/x86_64-w64-mingw32/lib/crt2.o /usr/lib/gcc/x86_64-w64-mingw32/7.1.1/crtbegin.o -L/usr/lib/gcc/x86_64-w64-mingw32/7.1.1 -L/usr/lib/gcc/x86_64-w64-mingw32/7.1.1 -L/usr/x86_64-w64-mingw32/lib -L/usr/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib /tmp/program-26420f.o -lstdc++ --start-group -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 --end-group /usr/lib/gcc/x86_64-w64-mingw32/7.1.1/crtend.o /tmp/program-26420f.o:(.text+0xa2): undefined reference to `__imp___dynamic_cast' /tmp/program-26420f.o:(.text+0xb7): undefined reference to `__imp___cxa_bad_cast' /tmp/program-26420f.o:(.text+0xf1): undefined reference to `__imp___cxa_begin_catch' /tmp/program-26420f.o:(.text+0x146): undefined reference to `__imp___cxa_end_catch' /tmp/program-26420f.o:(.text+0x161): undefined reference to `__imp___cxa_end_catch' /tmp/program-26420f.o:(.text[__clang_call_terminate]+0x7): undefined reference to `__imp___cxa_begin_catch' clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) ``` There is an associated issue on github: https://github.com/tpoechtrager/wclang/issues/32 The author of wclang has some insight of what is happening here: https://github.com/tpoechtrager/wclang/issues/32#issuecomment-320678320 -- 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 34123] New: Clangd fails with 'LLVM ERROR: inconsistency in registered CommandLine options' with deb package
https://bugs.llvm.org/show_bug.cgi?id=34123 Bug ID: 34123 Summary: Clangd fails with 'LLVM ERROR: inconsistency in registered CommandLine options' with deb package Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: marc-andre.lape...@ericsson.com CC: llvm-bugs@lists.llvm.org Using Ubuntu 16.04 with this repo: deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial main When I run clangd, I get this: $ clangd-6.0 : CommandLine Error: Option 'help-list' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options This seems similar to bug 22543 Maybe something needs to be fixed on the Clangd side? But I do not get this error when I compile clangd from SVN trunk. -- 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 34124] New: building compiler-rt on FreeBSD tries to link against non-existent libstdc++
https://bugs.llvm.org/show_bug.cgi?id=34124 Bug ID: 34124 Summary: building compiler-rt on FreeBSD tries to link against non-existent libstdc++ Product: compiler-rt Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Trying to build stock compiler-rt on FreeBSD -CURRENT fails with: /usr/bin/ld: error: unable to find library -lstdc++ clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) In the default FreeBSD environment we have libc++ and libcxxrt. -- 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 34125] New: Clang punts on vectorization and issues incorrect diagnostic
https://bugs.llvm.org/show_bug.cgi?id=34125
Bug ID: 34125
Summary: Clang punts on vectorization and issues incorrect
diagnostic
Product: clang
Version: 4.0
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jeff.scie...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18948
--> https://bugs.llvm.org/attachment.cgi?id=18948&action=edit
make command output
Clang claims the reason it does not vectorize star[45] is because the trip
count cannot be determined, but the trip count determination is identical in
star[123], which are vectorized.
./stencil_tbb.hpp:63:7: remark: loop not vectorized: could not determine number
of loop iterations [-Rpass-analysis]
for (auto j=r.cols().begin(); j!=r.cols().end(); ++j ) {
^
As best I can tell, the issue is that the loop bodies for star[45] are too
large. Functions with 12 or fewer terms are vectorized whereas those with 16
or more are not.
--
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 34126] New: 128-bit software floating point division does not update FP environment for hardware cores
https://bugs.llvm.org/show_bug.cgi?id=34126 Bug ID: 34126 Summary: 128-bit software floating point division does not update FP environment for hardware cores Product: compiler-rt Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: compn...@compnerd.org CC: llvm-bugs@lists.llvm.org The 128-bit floating point division routines need to update the floating point hardware state when performing operations (e.g. division by NaN). This needs to account for the various architectures in the target agnostic code path (e.g. targeting Cortex M3 could not do 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 33829] implement a structured clang-fuzzer (aka clang-proto-fuzzer)
https://bugs.llvm.org/show_bug.cgi?id=33829 Matt Morehouse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Matt Morehouse --- Integrated with LLVM in r310408. -- 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 33241] compiling chromium Segmentation fault
https://bugs.llvm.org/show_bug.cgi?id=33241 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC||h...@chromium.org Resolution|--- |INVALID --- Comment #1 from Hans Wennborg --- Sorry, since there is no attached source, there is nothing we can do here. Tofues, if this still reproduces, please re-open and attach the files as suggested by the crash message. -- 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 33252] 5.0.0-svn300007-1~exp1 segfault llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator
https://bugs.llvm.org/show_bug.cgi?id=33252 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Hans Wennborg --- > clang: 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: note: diagnostic msg: > > > sources are 213M (bz compresses). Unfortunately we still need the preprocessed source to be able to deal with this. Please re-open if this issue is still occurring, and try to upload the source 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 34127] New: [AArch64] Add support for stack protector using pointer authentication
https://bugs.llvm.org/show_bug.cgi?id=34127 Bug ID: 34127 Summary: [AArch64] Add support for stack protector using pointer authentication Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: mcros...@codeaurora.org CC: llvm-bugs@lists.llvm.org The ARMV8.3a extensions add new instructions for pointer authentication. We should use these instructions to optimize the -fstack-protector implementation. This feature is already present in GCC. -- 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 34128] New: Clang sets ItaniumCXXABI's __non_diamond_repeat_mask flag more often than GCC/ICC
https://bugs.llvm.org/show_bug.cgi?id=34128
Bug ID: 34128
Summary: Clang sets ItaniumCXXABI's __non_diamond_repeat_mask
flag more often than GCC/ICC
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: ryan.prich...@gmail.com
CC: llvm-bugs@lists.llvm.org
Consider this class hierarchy (each name is a subobject -- Shared is a virtual
base class):
Base
^
|
+--+
|Shared|
+--+
^^
||
||
LeftRight
^^
||
||
Root
The Itanium ABI specifies a __vmi_class_type_info for the Root class because it
has two base classes. The __vmi_class_type_info object has two flags, declared
like so in the libcxxabi source:
enum {
__non_diamond_repeat_mask = 0x1, // has two or more distinct base class
//objects of the same type
__diamond_shaped_mask = 0x2 // has base class object with two or
//more derived objects
};
For this class hierarchy, GCC leaves Root's __non_diamond_repeat_mask flag
clear, which matches the comment in the libcxxabi header, whereas Clang sets
the flag. From a reliability/interoperability standpoint, maybe it'd be nice if
the compilers were consistent. The IA64ABI document's definitions of the two
flags weren't clear to me, so I'm not sure that Clang's behavior is technically
wrong. I also checked ICC via godbolt, which AFAIK uses the EDG frontend's
independent implementation of the IA64ABI, and it also clears the flag.
In libcxxabi, I think the two flags are only used for dynamic_cast, and I don't
think incorrectly setting the flag would ever break dynamic_cast. (Clearing it
would.)
In general, incorrectly setting the flag makes dynamic_cast slower. I don't
know whether fixing this particular issue would help.
Here's a test case demonstrating the inconsistency:
#include
#include
struct Base { virtual ~Base() {} };
struct Shared : Base {};
struct Left : virtual Shared {};
struct Right : virtual Shared {};
struct Root : Left, Right {};
Root root;
enum {
non_diamond_repeat_mask = 0x1, // has two or more distinct base class
//objects of the same type
diamond_shaped_mask = 0x2 // has base class object with two or
//more derived objects
};
// type info for classes that
// - have two or more base classes, or
// - have at least 1 virtual base class.
struct vmi_class_type_info {
virtual ~vmi_class_type_info();
const char *name;
unsigned int flags;
unsigned int base_count;
};
int main() {
const vmi_class_type_info &info =
reinterpret_cast(typeid(root));
printf("info.name=[%s]\n", info.name);
printf("info.flags=%d:\n", info.flags);
if (info.flags & non_diamond_repeat_mask) {
printf(" non_diamond_repeat_mask\n");
}
if (info.flags & diamond_shaped_mask) {
printf(" diamond_shaped_mask\n");
}
printf("info.base_count=%d\n", info.base_count);
return 0;
}
Output (tested on Ubuntu 16.04):
$ g++ test.cc && ./a.out
name=[4Root]
info->flags=2:
__diamond_shaped_mask
info->base_count=2
$ clang++ test.cc && ./a.out
name=[4Root]
info->flags=3:
__non_diamond_repeat_mask
__diamond_shaped_mask
info->base_count=2
--
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 33193] Crash due to unhandled cast causing an UNREACHABLE to be executed at llvm/include/llvm/CodeGen/BasicTTIImpl.h:590
https://bugs.llvm.org/show_bug.cgi?id=33193 Douglas Yung changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Douglas Yung --- Yes, it appears that change fixed it, so resolving this bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33363] crash with "-O3 -m32" on x86_64-linux-gnu (Assertion `SA->getUseBlocks().size() == 1 && "Not a local interval"' failed.)
https://bugs.llvm.org/show_bug.cgi?id=33363 Hans Wennborg changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- I can't reproduce on 5.0 or trunk. Perhaps it got 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 34129] New: Add tests
https://bugs.llvm.org/show_bug.cgi?id=34129 Bug ID: 34129 Summary: Add tests Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: opt-viewer Assignee: unassignedb...@nondot.org Reporter: ane...@apple.com CC: ane...@apple.com, llvm-bugs@lists.llvm.org Currently the opt-viewer tools are untested. We should add some tests. A few notes about this: * This needs some REQUIRES check so that we don't run this when people don't have the appropriate python packages (pyyaml, pygments) installed * Rather than detecting the packages for now we could just add a CMAKE flag that enables these. Then people changing the opt-viewer would be expected to configure with this flag. We could also have a bot with this flag. -- 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 33365] LLVM Crashed in X86 DAG->DAG Instruction Selection, with -fprofile-generate
https://bugs.llvm.org/show_bug.cgi?id=33365 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Hans Wennborg --- (In reply to Nirav Dave from comment #4) > Looks like it's related to pr32659. r305070 should fix the underlying > problem. I can't reproduce, so I assume this was 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 33460] Assertion failed: NewElts && "Out of memory" on a simple program
https://bugs.llvm.org/show_bug.cgi?id=33460 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Hans Wennborg --- It seems the attached file contains the link to a Dropbox file which in turn just contains the URL to a GMail attachment which I'm not able to open. Can you upload the file itself to Dropbox instead? Marking as invalid in the meantime since we cannot do much without source code. -- 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 33555] clang-cl compilation fails
https://bugs.llvm.org/show_bug.cgi?id=33555 Hans Wennborg changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #4 from Hans Wennborg --- I can reproduce at r303050 which you used, but not at the 5.0 branch or trunk, so this must have been fixed at some point. -- 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 33577] [KNL] crash in X86 DAG->DAG Instruction Selection
https://bugs.llvm.org/show_bug.cgi?id=33577 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #3 from Hans Wennborg --- Sounds like it doesn't reproduce on trunk. Please re-open if this is still an issue. -- 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 33617] clang (rev. 305643) crashes while building kwin 5.10.3
https://bugs.llvm.org/show_bug.cgi?id=33617 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #6 from Hans Wennborg --- I can reproduce with an older version of trunk, but not the current one or 5.0, so this must have been fixed at some point. Please re-open if it's still a problem. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34027] clang++.exe: error: clang frontend command failed due to signal
https://bugs.llvm.org/show_bug.cgi?id=34027 Hans Wennborg changed: What|Removed |Added Resolution|--- |INVALID CC||h...@chromium.org Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- Can you attach the preprocessed source and run script mentioned in the crash output? Otherwise we cannot 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 33589] SourceColumnMap::byteToContainingColumn(int) const: Assertion `0 <= N && N < static_cast(m_byteToColumn.size())' failed
https://bugs.llvm.org/show_bug.cgi?id=33589 Bernhard Rosenkraenzer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Bernhard Rosenkraenzer --- This has been fixed - works as expected in rev 310074. -- 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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33589, which changed state. Bug 33589 Summary: SourceColumnMap::byteToContainingColumn(int) const: Assertion `0 <= N && N < static_cast(m_byteToColumn.size())' failed https://bugs.llvm.org/show_bug.cgi?id=33589 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 34109] Crash @clang::Sema::MarkFunctionReferenced
https://bugs.llvm.org/show_bug.cgi?id=34109 rtr...@google.com changed: What|Removed |Added CC||rtr...@google.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from rtr...@google.com --- Fixed in r310435. -- 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 34131] New: lld crashes during LTO build
https://bugs.llvm.org/show_bug.cgi?id=34131 Bug ID: 34131 Summary: lld crashes during LTO build Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org ld.lld: ../../lib/Analysis/ValueTracking.cpp:1500: void computeKnownBits(const llvm::Value *, llvm::KnownBits &, unsigned int, const (anonymous namespace)::Query &): Assertion `Depth <= MaxDepth && "Limit Search Depth"' failed. #0 0x020fa7f9 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Unix/Signals.inc:398:11 #1 0x020fa9a9 PrintStackTraceSignalHandler(void*) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Unix/Signals.inc:462:1 #2 0x020f9013 llvm::sys::RunSignalHandlers() /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Signals.cpp:0:5 #3 0x020fad04 SignalHandler(int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Unix/Signals.inc:252:1 #4 0x7f3b1c7df330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #5 0x7f3b1b3cec37 gsignal /build/eglibc-SvCtMH/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x7f3b1b3d2028 abort /build/eglibc-SvCtMH/eglibc-2.19/stdlib/abort.c:91:0 #7 0x7f3b1b3c7bf6 __assert_fail_base /build/eglibc-SvCtMH/eglibc-2.19/assert/assert.c:92:0 #8 0x7f3b1b3c7ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #9 0x04ec9787 computeKnownBits(llvm::Value const*, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:1501:23 #10 0x04ec9706 llvm::computeKnownBits(llvm::Value const*, llvm::KnownBits&, llvm::DataLayout const&, unsigned int, llvm::AssumptionCache*, llvm::Instruction const*, llvm::DominatorTree const*, llvm::OptimizationRemarkEmitter*) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:144:1 #11 0x04edda54 isTruePredicate(llvm::CmpInst::Predicate, llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, unsigned int)::$_9::operator()(llvm::Value const*, llvm::Value const*, llvm::Value const*&, llvm::APInt const*&, llvm::APInt const*&) const /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4416:9 #12 0x04edd7a0 isTruePredicate(llvm::CmpInst::Predicate, llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4427:9 #13 0x04edd54e isImpliedCondOperands(llvm::CmpInst::Predicate, llvm::Value const*, llvm::Value const*, llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4454:67 #14 0x04ed39d1 isImpliedCondICmps(llvm::ICmpInst const*, llvm::ICmpInst const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4558:5 #15 0x04ed361a llvm::isImpliedCondition(llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4621:5 #16 0x04ed3c94 isImpliedCondAndOr(llvm::BinaryOperator const*, llvm::ICmpInst const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4588:24 #17 0x04ed3688 llvm::isImpliedCondition(llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4629:7 #18 0x04ed3bd2 isImpliedCondAndOr(llvm::BinaryOperator const*, llvm::ICmpInst const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4585:24 #19 0x04ed3688 llvm::isImpliedCondition(llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4629:7 #20 0x04ed3bd2 isImpliedCondAndOr(llvm::BinaryOperator const*, llvm::ICmpInst const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Analysis/ValueTracking.cpp:4585:24 #21 0x04ed3688 llvm::isImpliedCondition(llvm::Value const*, llvm::Value const*, llvm::DataLayout const&, bool, unsigned int) /usr/local/google/home/phosek/clang-llvm/llvm/out/
[llvm-bugs] [Bug 34132] New: LTO optimization causes clang to produce incorrect code
https://bugs.llvm.org/show_bug.cgi?id=34132
Bug ID: 34132
Summary: LTO optimization causes clang to produce incorrect
code
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: konstantin.belocha...@sony.com
CC: llvm-bugs@lists.llvm.org
source.c:
#include
struct {
unsigned char a[4];
unsigned char b[4];
} s;
static void init_arr(volatile void *data, unsigned char size) {
unsigned char *bytes = (unsigned char *)data;
for (unsigned char i = 0; i != size; ++i) {
bytes[i] = i;
}
}
int main() {
init_arr(&s, sizeof(s) );
printf("a:%x %x %x %x\n", s.a[0], s.a[1], s.a[2], s.a[3]);
printf("b:%x %x %x %x\n", s.b[0], s.b[1], s.b[2], s.b[3]);
}
clang -Oz -flto source.c
or
clang -O0 -flto source.c
or
clang -O1 -flto source.c
:
xor%eax,%eax
lea0x7fcb(%rip),%rcx# 80a8 <__preinit_array_end>
jmpe5 <__start__Zdynsym+0x5>
mov%al,(%rax,%rcx,1)
inc%rax
cmp$0x8,%rax
jnedf <__dynstr_end+0x6>
push %rbp
mov%rsp,%rbp
movzbl 0x7fb2(%rip),%esi# 80a8 <__preinit_array_end>
movzbl 0x7fac(%rip),%edx# 80a9 <__preinit_array_end+0x1>
movzbl 0x7fa6(%rip),%ecx# 80aa <__preinit_array_end+0x2>
movzbl 0x7f9f(%rip),%r8d# 80ab <__preinit_array_end+0x3>
lea0xdd(%rip),%rdi# 1f0 <.L.str>
xor%eax,%eax
callq 1a0
lea0xde(%rip),%rdi# 1ff <.L.str.1>
xor%esi,%esi
xor%edx,%edx
xor%ecx,%ecx
xor%r8d,%r8d
xor%eax,%eax
callq 1a0
xor%eax,%eax
pop%rbp
retq
With LTO optimization clang assumes that s.b[0] == s.b[1] == s.b[2] == s.b[3]
== 0 and generates all zero values for the second printf().
With optimization level -O2 or -O3 and -flto, clang produces correct code:
:
push %rbp
mov%rsp,%rbp
lea0xf5(%rip),%rdi# 1e0 <.L.str>
mov$0x0,%esi
mov$0x1,%edx
mov$0x2,%ecx
mov$0x3,%r8d
xor%eax,%eax
callq 190
lea0xe1(%rip),%rdi# 1ef <.L.str.1>
mov$0x4,%esi
mov$0x5,%edx
mov$0x6,%ecx
mov$0x7,%r8d
xor%eax,%eax
callq 190
xor%eax,%eax
pop%rbp
retq
--
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 29160] clang is 36.5 times slower than gcc
https://bugs.llvm.org/show_bug.cgi?id=29160 George Burgess changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from George Burgess --- Should be fixed by r310436 + r310437. Building the test-case with -O2 -DCHUNKS=42 on my machine now takes ~740ms. Thanks again! -- 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 32864] tools/clang/include/clang/AST/APValue.h:314: clang::APValue &clang::APValue::getStructField(unsigned int): Assertion `isStruct() && "Invalid accessor"' failed.
https://bugs.llvm.org/show_bug.cgi?id=32864 Yaron Keren changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Yaron Keren --- yes, it is solved. -- 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 32331] symbol defined in linker script populated with incorrect address
https://bugs.llvm.org/show_bug.cgi?id=32331 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from George Rimar --- Looks fixed in HEAD (basing on comments). -- 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 32902] Assertion failed: (V->getType()->isPointerTy() && "V must be pointer type")
https://bugs.llvm.org/show_bug.cgi?id=32902 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Davide Italiano --- r306379 -- 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
