[llvm-bugs] [Bug 32960] New: debian repo for http://apt.llvm.org/xenial/ seems broken
https://bugs.llvm.org/show_bug.cgi?id=32960 Bug ID: 32960 Summary: debian repo for http://apt.llvm.org/xenial/ seems broken Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: juhpeter...@gmail.com CC: llvm-bugs@lists.llvm.org This started happening in the last few weeks: The following packages have unmet dependencies: llvm-4.0 : Depends: llvm-4.0-runtime (= 1:4.0~svn301550-1~exp1) but it is not going to be installed Depends: libllvm4.0 (>= 1:4.0-3~) but it is not going to be installed Recommends: llvm-4.0-dev but it is not going to be installed -- 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 32961] New: [Polly] Unknown OpenCL identifiers
https://bugs.llvm.org/show_bug.cgi?id=32961 Bug ID: 32961 Summary: [Polly] Unknown OpenCL identifiers Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org With recent Polly versions and GPU code generation enabled, I get the following errors: /home/grosser/Projects/polly/git/tools/polly/tools/GPURuntime/GPUJIT.c:862:8: error: use of undeclared identifier 'CL_INVALID_PIPE_SIZE' case CL_INVALID_PIPE_SIZE: ^ /home/grosser/Projects/polly/git/tools/polly/tools/GPURuntime/GPUJIT.c:865:8: error: use of undeclared identifier 'CL_INVALID_DEVICE_QUEUE' case CL_INVALID_DEVICE_QUEUE: ^ 2 errors generated. Best, Tobias -- 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 32875] gcc attribute abi_tag not working correctly?
https://bugs.llvm.org/show_bug.cgi?id=32875 jorgen...@kcg.com changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #17 from jorgen...@kcg.com --- My working copy had local changes from a previous abi-tag patch. Ouch! Mea culpa. -- 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 32962] New: ConvertUTF.cpp is shipped with a non "University of Illinois Open Source License" compatible license
https://bugs.llvm.org/show_bug.cgi?id=32962 Bug ID: 32962 Summary: ConvertUTF.cpp is shipped with a non "University of Illinois Open Source License" compatible license Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: sylves...@debian.org CC: llvm-bugs@lists.llvm.org Detected by lintian, the Debian static analyzer: lib/Support/ConvertUTF.cpp include material under a non-free license from Unicode Inc. Therefore, it is not possible to ship this in main or contrib. This license does not grant any permission to modify the files (thus failing DFSG#3). Moreover, the license grant to attempt to restrict use to "products supporting the Unicode Standard" (thus failing DFSG#6). In this case a solution is to use libicu and to remove this code by repacking. Refer to https://bugs.debian.org/823100 for details. And https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines for Debian information. -- 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 32963] New: Incorrect implementation of LWG 2534
https://bugs.llvm.org/show_bug.cgi?id=32963
Bug ID: 32963
Summary: Incorrect implementation of LWG 2534
Product: libc++
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zi...@kayari.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
#include
int main()
{
std::ostream& os = std::move(std::cout) << "http://wg21.link/lwg2534";;
os << '\n';
}
prog.cc:5:19: error: non-const lvalue reference to type 'basic_ostream<...>'
cannot bind to a temporary of type 'basic_ostream<...>'
std::ostream& os = std::move(std::cout) << "http://wg21.link/lwg2534";;
^~~
The return type should be an lvalue reference.
The SFINAE constraint on the operator<< for rvalue streams also seem wrong.
This shouldn't compile because the constraint is not met:
#include
struct X : std::ios_base { };
struct Y { };
template
struct is_streamable
: std::false_type { };
template
struct is_streamable() <<
std::declval())>
: std::true_type { };
static_assert( !is_streamable::value, "" );
decltype(std::declval() << std::declval()) f();
const auto& ff = f();
--
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 32964] New: load from @i hoisted before store to @i by -speculative-execution
https://bugs.llvm.org/show_bug.cgi?id=32964 Bug ID: 32964 Summary: load from @i hoisted before store to @i by -speculative-execution Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 18415 --> https://bugs.llvm.org/attachment.cgi?id=18415&action=edit reproducer opt -S -speculative-execution -o - spec.ll In the input we have: entry: %0 = load i8, i8* @i %tobool = icmp eq i8 %0, 0 br i1 %tobool, label %if.end, label %if.then if.then: ; preds = %entry store i8 0, i8* @i %.pre = load i8, i8* @i br label %if.end and in the output we get: entry: %0 = load i8, i8* @i %tobool = icmp eq i8 %0, 0 %.pre = load i8, i8* @i br i1 %tobool, label %if.end, label %if.then if.then: ; preds = %entry store i8 0, i8* @i br label %if.end so %.pre = load i8, i8* @i has been moved before store i8 0, i8* @i and we'll load the old (wrong) value. This started going wrong after commit SpeculativeExecution: Stop using whitelist for costs but I suppose that is because costs in general went down with that patch so it triggers in more cases. This seems very broken to me and I see these errors a lot in our out-of-tree backend. -- 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 32965] New: ODRHash hashes type sugar
https://bugs.llvm.org/show_bug.cgi?id=32965 Bug ID: 32965 Summary: ODRHash hashes type sugar Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: vvasi...@cern.ch CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 18416 --> https://bugs.llvm.org/attachment.cgi?id=18416&action=edit A standalone reproducer r301989 caused regression in our builds. We spent some time reducing and understanding the example. To use reproduce it open test.sh rewire your compiler and run it. The output is: rm -fr pcms/* ; "/Users/vvassilev/workspace/llvm-git/obj/bin/clang++" -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -main-file-name TGQt.cxx -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -resource-dir `pwd`/cvmfs/sft.cern.ch/lcg/contrib/llvm/builds/x86_64-slc6-gcc62-opt/clang_build_302187/lib/clang/5.0.0 -D QT_CORE_LIB -D QT_GUI_LIB -I ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/include -internal-isystem `pwd`/afs/cern.ch/sw/lcg/contrib/gcc/6.2/x86_64-slc6/include/c++/6.2.0 -internal-isystem `pwd`/afs/cern.ch/sw/lcg/contrib/gcc/6.2/x86_64-slc6/include/c++/6.2.0/x86_64-pc-linux-gnu -internal-isystem `pwd`/afs/cern.ch/sw/lcg/contrib/gcc/6.2/x86_64-slc6/include/c++/6.2.0/backward -internal-isystem `pwd`/cvmfs/sft.cern.ch/lcg/contrib/llvm/builds/x86_64-slc6-gcc62-opt/clang_build_302187/lib/clang/5.0.0/include -internal-externc-isystem `pwd`/usr/include -Wshadow -Wall -W -Woverloaded-virtual -Wc++11-narrowing -Wsign-compare -Wsometimes-uninitialized -Wconditional-uninitialized -Wheader-guard -Warray-bounds -Wcomment -Wtautological-compare -Wstrncat-size -Wloop-analysis -Wbool-conversion -Wno-module-import-in-extern-c -Wno-deprecated-register -Wno-deprecated -Wno-uninitialized -std=c++11 -fno-autolink -fdebug-compilation-dir ./build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/standalone -ferror-limit 19 -fmessage-length 114 -pthread -fmodules -fimplicit-module-maps -fmodules-cache-path=./pcms/ -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fdiagnostics-show-note-include-stack -fcolor-diagnostics -fmodules-local-submodule-visibility -x c++ ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/TGQt.cxx -nostdsysteminc -Rmodule-build ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/TGQt.cxx:27:10: remark: building module 'libGQt.so' as '/Users/vvassilev/workspace/reproducers/PR_ODRVisitor2/standalone/pcms/1LGRIN2OWEDGY/libGQt.so-3TBZLKNN4S8RG.pcm' [-Rmodule-build] #include "TGQt.h" ^ ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/TGQt.cxx:27:10: remark: finished building module 'libGQt.so' [-Rmodule-build] In file included from ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/TGQt.cxx:22: ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/include/qstring1.h:9:8: error: 'QString' has different definitions in different modules; first difference is defined here found method 'vsprintf' with 2nd parameter of type '__va_list_tag *' decayed from 'va_list' (aka '__builtin_va_list') void vsprintf(const char *format, va_list ap); ~^~~~ In module 'libGQt.so' imported from ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/TGQt.cxx:27: ./mnt/build/jenkins/workspace/root-nightly-cxxmodules/BUILDTYPE/Debug/COMPILER/clang_gcc62/LABEL/slc6/build/include/qstring1.h:9:8: note: but in 'libGQt.so.TGQt.h' found method 'vsprintf' with 2nd parameter of type '__va_list_tag *' decayed from 'va_list' (aka '__builtin_va_list') void vsprintf(const char *format, va_list ap); ~^~~~ 1 error 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 32967] New: AVX512: 'shuffle <32 x i16> v0, v1, <8 x i32> Mask' is scalarized
https://bugs.llvm.org/show_bug.cgi?id=32967
Bug ID: 32967
Summary: AVX512: 'shuffle <32 x i16> v0, v1, <8 x i32> Mask' is
scalarized
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: zvi.racko...@intel.com
CC: llvm-bugs@lists.llvm.org
For the following function
define <8 x i16> @shuffle_odd_stride4(<32 x i16> %v) {
%shuffle = shufflevector <32 x i16> %v, <32 x i16> undef, <8 x i32>
ret <8 x i16> %shuffle
}
llc -mcpu=skx gives:
vpextrw $5, %xmm0, %eax
vpextrw $1, %xmm0, %ecx
vmovd %ecx, %xmm1
vpinsrw $1, %eax, %xmm1, %xmm1
vextracti32x4 $1, %zmm0, %xmm2
vpextrw $1, %xmm2, %eax
vpinsrw $2, %eax, %xmm1, %xmm1
vpextrw $5, %xmm2, %eax
vpinsrw $3, %eax, %xmm1, %xmm1
vextracti32x4 $2, %zmm0, %xmm2
vpextrw $1, %xmm2, %eax
vpinsrw $4, %eax, %xmm1, %xmm1
vpblendw {{.*#+}} xmm1 = xmm1[0,1,2,3,4],xmm2[5],xmm1[6,7]
vextracti32x4 $3, %zmm0, %xmm0
vpextrw $1, %xmm0, %eax
vpinsrw $6, %eax, %xmm1, %xmm1
vpextrw $5, %xmm0, %eax
vpinsrw $7, %eax, %xmm1, %xmm0
The problem here seems to be more related to the ratio of
in_vec_len/out_vec_len=4 than the shuffle mask indices.
--
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 32968] New: posix_memalign should return ENOMEM when allocation fails under allocator_may_return_null=1
https://bugs.llvm.org/show_bug.cgi?id=32968 Bug ID: 32968 Summary: posix_memalign should return ENOMEM when allocation fails under allocator_may_return_null=1 Product: new-bugs Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tim.g.armstr...@gmail.com CC: llvm-bugs@lists.llvm.org ASAN's posix_memalign() should return ENOMEM when the allocation fails due to lack of memory. I can reproduce this reliably by making a huge allocation (e.g. 2^48 bytes) with ASAN_OPTIONS including allocator_may_return_null=1. A null pointer is returned via the output argument but the return value is 0 (which means success). -- 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 32876] Broken dependency on libllvm4.0 [apt repository Ubuntu Xenial]
https://bugs.llvm.org/show_bug.cgi?id=32876 Sylvestre Ledru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sylvestre Ledru --- Fixed with: https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/4.0/debian/rules?r1=2587&r2=2593 I recompiled xenial, I just retriggered the other builds sorry about that -- 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 32969] New: clang-format breaks array initializer in unexpected places
https://bugs.llvm.org/show_bug.cgi?id=32969
Bug ID: 32969
Summary: clang-format breaks array initializer in unexpected
places
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: luka...@chromium.org
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Given the following (manually formatted) snippet...
bool IsBlacklistedInstanceMethodName(llvm::StringRef name) {
static const char* kBlacklistedNames[] = {
// We should avoid renaming the method names listed below, because
// 1. They are used in templated code (e.g. in )
// 2. They (begin+end) are used in range-based for syntax sugar
//- for (auto x : foo) { ... } // <- foo.begin() will be called.
"begin", "end", "rbegin", "rend", "lock", "unlock", "try_lock",
// https://crbug.com/672902: Should not rewrite names that mimick methods
// from std library.
"at", "back", "clear" "empty", "erase", "find", "front", "insert",
"length", "size", "swap",
};
for (const auto& b : kBlacklistedNames) {
if (name == b)
return true;
}
return false;
}
clang-format reformats it to:
bool IsBlacklistedInstanceMethodName(llvm::StringRef name) {
static const char* kBlacklistedNames[] = {
// We should avoid renaming the method names listed below, because
// 1. They are used in templated code (e.g. in )
// 2. They (begin+end) are used in range-based for syntax sugar
//- for (auto x : foo) { ... } // <- foo.begin() will be called.
"begin", "end", "rbegin", "rend", "lock", "unlock", "try_lock",
// https://crbug.com/672902: Should not rewrite names that mimick methods
// from std library.
"at", "back",
"clear"
"empty",
"erase", "find", "front", "insert", "length", "size", "swap",
};
for (const auto& b : kBlacklistedNames) {
if (name == b)
return true;
}
return false;
}
I am rather surprised that 1) any reformatting is needed at all, 2) that
results take more lines than the original formatting, 3) that the line breaks
seem randomly placed (e.g. *why* after "back", and "clear" and "empty", but not
after "at" or "erase").
--
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 32550] GlobalISel -O0 for AArch64 moves floating point values through GPRs way too often
https://bugs.llvm.org/show_bug.cgi?id=32550 Quentin Colombet changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Quentin Colombet --- I actually took a different approach here. Instead of having to rely on the greedy mode at O0, I changed the default mapping of loads such that loads feeding fp instructions get FPR mapping. This is r302453. -- 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 32961] [Polly] Unknown OpenCL identifiers
https://bugs.llvm.org/show_bug.cgi?id=32961 Philipp Schaad changed: What|Removed |Added Resolution|--- |FIXED CC||phsch...@student.ethz.ch Status|NEW |RESOLVED --- Comment #1 from Philipp Schaad --- Fixed with https://reviews.llvm.org/D32962 -- 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 32941] FileCheck failure for a C-based unit test case
https://bugs.llvm.org/show_bug.cgi?id=32941 NAKAMURA Takumi changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from NAKAMURA Takumi --- Paul, thanks to clarify. Yonghong, I am certain there is no issue of FileCheck. Please ask in the mailing list, like llvm-dev or cfe-dev. -- 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 32970] New: -fno-short-enums does not work
https://bugs.llvm.org/show_bug.cgi?id=32970 Bug ID: 32970 Summary: -fno-short-enums does not work Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org While trying to write a unittest I noticed that -fno-short-enums does not appear to work correctly in clang. Example: $ cat t.cpp int x = sizeof(wchar_t); $ clang++ -target x86_64-unknown-windows-msvc -fno-short-enums t.cpp -S -o - ... "?x@@3HA": .long 2 # 0x2 I would have expected .long 4 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32971] New: [ppc] Highly predictable ISEL should be changed to cmp/br
https://bugs.llvm.org/show_bug.cgi?id=32971
Bug ID: 32971
Summary: [ppc] Highly predictable ISEL should be changed to
cmp/br
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
On power, use ISEL or cmp/br is a general hard problem. But if we can point out
the branch is highly predictable (either through runtime profiling or static
estimate), we should use cmp/br.
Following is a test case simplified from real world code.
#include
typedef std::vector MyVec;
int foo(int iters, MyVec* vec) {
MyVec::const_iterator it = vec->begin();
for (int i = 0; i < iters; ++i, ++it) {
if (it == vec->end()) {
it = vec->begin();
}
if (*it >= iters)
return 1;
}
return 0;
}
The iterator "it" is incremented in each iteration, and it is compared to the
same value vec->end(), so we can expect the condition is false for most times,
and then it is true, and then false again ...
So this branch is highly predictable. In our code, cmp/br is 2x faster than
isel.
LLVM generates following code, which uses ISEL
# BB#0: # %entry
cmpwi3, 1
blt 0, .LBB0_4
# BB#1: # %for.body.lr.ph
addi 6, 3, -1
ld 5, 0(4)
ld 4, 8(4)
clrldi 6, 6, 32
addi 6, 6, 1
mr 7, 5
mtctr 6
li 6, 0
.p2align5
.LBB0_2:# %for.body
# =>This Inner Loop Header: Depth=1
cmpld4, 7
isel 7, 5, 7, 2
lwz 8, 0(7)
cmpw 8, 3
bge 0, .LBB0_5
# BB#3: # %for.inc
# in Loop: Header=BB0_2 Depth=1
addi 6, 6, 1
addi 7, 7, 4
bdnz .LBB0_2
.LBB0_4:
li 3, 0
clrldi 3, 3, 32
blr
.LBB0_5:
li 3, 1
clrldi 3, 3, 32
blr
--
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 32970] -fno-short-wchar does not work
https://bugs.llvm.org/show_bug.cgi?id=32970 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Matthias Braun --- Seems the way to think about it is as an override to use `short` instead of whatever the platform default is. So the behavior is as design (though somewhat unexpected). -- 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
