[llvm-bugs] [Bug 31902] [btver2] Fix a crash in combineOrCmpEqZeroToCtlzSrl under fast math
https://llvm.org/bugs/show_bug.cgi?id=31902 pierre gousseau changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from pierre gousseau --- Fix commited https://reviews.llvm.org/rL294588 -- 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 31927] New: Invariant load hoisting miscompiles oggenc
https://llvm.org/bugs/show_bug.cgi?id=31927 Bug ID: 31927 Summary: Invariant load hoisting miscompiles oggenc Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified The following command line results in a miscompile: ~/mysandbox/bin/lnt runtest nt --sandbox /tmp/sandbox --cc ~/polly/build/bin/clang --test-suite /scratch/grosser/test-suite/ --mllvm=-polly --mllvm=-polly-invariant-load-hoisting --only-test MultiSource/Applications/oggenc 2017-02-10 14:21:19 INFO: inferred C++ compiler under test as: '/users/grosser/polly/build/bin/clang++' using r294734. -- 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 31928] New: After r280351: if/else blocks incorrectly optimized away?
https://llvm.org/bugs/show_bug.cgi?id=31928
Bug ID: 31928
Summary: After r280351: if/else blocks incorrectly optimized
away?
Product: new-bugs
Version: 4.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17965
--> https://llvm.org/bugs/attachment.cgi?id=17965&action=edit
Test case reduces from gdtoa's ratio() function
>From https://bugs.freebsd.org/216770, where we had some trouble building the
Julia port, we found out that clang 4.0.0 seems to miscompile gdtoa's [1]
ratio() function in smisc.c [2], leading to incorrect strtrod(3) output.
What seems to be happening is that after r280351 ("[SimplifyCFG] Change the
algorithm in SinkThenElseCodeToEnd"), the if/else block is either entirely
optimized away, or only the else block is.
The function itself takes unions of doubles and unsigned, and a parameter 'k'
which determines the fork to take in the if/else statement. Simplified:
typedef union {
double d;
unsigned L[2];
} U;
double ratio(U da, U db, int k)
{
if (k > 0) {
da.L[1] += k * 0x10;
} else {
k = -k;
db.L[1] += k * 0x10;
}
return da.d / db.d;
}
Trunk r280350 with -O2, targeting x86_64, compiles this to:
ratio: # @ratio
.cfi_startproc
# BB#0: # %entry
testl %edx, %edx
jle .LBB0_2
# BB#1: # %if.then
shll$20, %edx
movq%rdi, %rax
shrq$32, %rax
addl%edx, %eax
shlq$32, %rax
movl%edi, %edi
orq %rax, %rdi
jmp .LBB0_3
.LBB0_2:# %if.else
shll$20, %edx
movq%rsi, %rax
shrq$32, %rax
subl%edx, %eax
shlq$32, %rax
movl%esi, %esi
orq %rax, %rsi
.LBB0_3:# %if.end
movd%rdi, %xmm0
movd%rsi, %xmm1
divsd %xmm1, %xmm0
retq
while r280351 and later compile this to just:
ratio: # @ratio
.cfi_startproc
# BB#0: # %entry
movd%rdi, %xmm0
movd%rsi, %xmm1
divsd %xmm1, %xmm0
retq
E.g., the whole if/else block is now gone. I do not think the C code exhibits
undefined behavior, so getting rid of the if/else block is incorrect.
When targeting 32-bit x86, the results are slightly different, because adding a
printf of either the da or db parameter's d member changes the result. Without
the printf, the end result is correct, with the printf, the result is
incorrect. Also, printing the unsigned member of the union makes the result
correct again. Test case:
#include
typedef union {
double d;
unsigned L[2];
} U;
double ratio(U da, U db, int k)
{
printf("%f\n", da.d);
if (k > 0) {
da.L[1] += k * 0x10;
} else {
k = -k;
db.L[1] += k * 0x10;
}
return da.d / db.d;
}
Trunk r280350 using -m32 -O2 gives:
ratio: # @ratio
# BB#0: # %entry
pushl %edi
pushl %esi
subl$36, %esp
movsd 48(%esp), %xmm0 # xmm0 = mem[0],zero
movl64(%esp), %edi
leal56(%esp), %esi
movsd %xmm0, 4(%esp)
movsd %xmm0, 16(%esp) # 8-byte Spill
movl$.L.str, (%esp)
calll printf
testl %edi, %edi
jle .LBB0_2
# BB#1: # %if.then
leal48(%esp), %eax
shll$20, %edi
addl%edi, 4(%eax)
movsd (%eax), %xmm0 # xmm0 = mem[0],zero
jmp .LBB0_3
.LBB0_2:# %if.else
shll$20, %edi
movsd 16(%esp), %xmm0 # 8-byte Reload
# xmm0 = mem[0],zero
subl%edi, 4(%esi)
.LBB0_3:# %if.end
divsd (%esi), %xmm0
movsd %xmm0, 24(%esp)
fldl24(%esp)
addl$36, %esp
popl%esi
popl%edi
retl
Trunk r280351 using -m32 -O2 gives:
ratio: # @ratio
# BB#0: # %entry
pushl %edi
pushl %esi
subl$36, %esp
movl64(%esp), %esi
movsd 48(%esp), %xmm0 # xmm0 = mem[0],zero
movl%esi, %edi
movsd %xmm0, 4(%esp)
movsd %xmm0, 16(%esp) # 8-byte Spill
movl
[llvm-bugs] [Bug 30760] Failing to vector constant fold vXi64 on 32-bit targets
https://llvm.org/bugs/show_bug.cgi?id=30760 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Fixed by rL294749 -- 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 31929] New: branch condition should be known from llvm.assume
https://llvm.org/bugs/show_bug.cgi?id=31929
Bug ID: 31929
Summary: branch condition should be known from llvm.assume
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Filing this based on the request in:
https://reviews.llvm.org/D28204
These are purposely minimized to be instcombine tests. If we decide that the
functionality doesn't belong there, then the tests may require additional
instructions to thwart other transformations (phi -> select) and/or trigger
from a different pass (LICM?).
-
declare void @llvm.assume(i1)
define i8 @assume_guarantees_notnull(i8* %x) {
entry:
%notnull = icmp ne i8* %x, null
tail call void @llvm.assume(i1 %notnull)
br i1 %notnull, label %if, label %endif <--- condition is known true
if:
%ld = load i8, i8* %x
br label %endif
endif:
%sel = phi i8 [ 0, %entry ], [ %ld, %if ]
ret i8 %sel
}
Depending on how we want to solve this, it may be relevant to use a non-pointer
value in the icmp:
define i8 @assume_guarantees_notnull(i8 %y, i8* %x) {
entry:
%notnull = icmp ne i8 %y, 0 <--- type shouldn't matter?
tail call void @llvm.assume(i1 %notnull)
br i1 %notnull, label %if, label %endif
if:
%ld = load i8, i8* %x, align 1
br label %endif
endif:
%sel = phi i8 [ 0, %entry ], [ %ld, %if ]
ret i8 %sel
}
For reference, we handle the 'select' variant of these examples in instcombine
by calling computeKnownBits when we know there might be an assumption that
defines the condition. That was bug 31512 / https://reviews.llvm.org/rL291915 .
--
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 31930] New: Optimization of loop via loop peeling does not occur for float and double
https://llvm.org/bugs/show_bug.cgi?id=31930
Bug ID: 31930
Summary: Optimization of loop via loop peeling does not occur
for float and double
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: drr...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
float f(float x[]) {
float p = 1.0;
for (int i = 0; i < 960; i++)
p += 1;
return p;
}
When compiled with -march=core-avx2 -O3 -ffast-math the assembly loops round
adding until it gets to 961.
However:
int f(int x[]) {
int p = 1;
for (int i = 0; i < 960; i++)
p += 1;
return p;
}
gives:
f: # @f
mov eax, 961
ret
I don't know how hard it would be to add the same optimization for floats and
double.
As a side note, there are in fact a number of interesting details with the
first (float) loop. First, if we reduce the i < 960 limit to i < 959 the loop
is optimized out. Second if we change the type to 'double' this upper limit
goes down to i < 479. My guess is that this corresponds to an unpeeling cost
model that is incorporated into the compiler.
--
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 31908] formatter doesn't understand preprocessor directives such as __has_include and incorrectly reformats them
https://llvm.org/bugs/show_bug.cgi?id=31908 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED CC||nicolaswe...@gmx.de Resolution|--- |FIXED --- Comment #1 from Nico Weber --- r294772. -- 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 31931] New: [Windows] Incorrect name mangling for "vbase destructor".
https://llvm.org/bugs/show_bug.cgi?id=31931 Bug ID: 31931 Summary: [Windows] Incorrect name mangling for "vbase destructor". Product: clang Version: 3.9 Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: e...@andante.org CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17966 --> https://llvm.org/bugs/attachment.cgi?id=17966&action=edit Testcase which demonstrates the bug. There are a couple of name mangling bugs in llvm/clang that I am noticing - they always seem to have to do with "vbase destructors". The enclosed testcase demonstrates this. Clang generates symbol references like such: 0:000 T ??_Dbasic_istream@@UAE@XZ 0:000 T ??_Dbasic_istringstream@@UAE@XZ The same source, when compiled with visual studio 2013, generates these symbols in the object file: 0:000 ? ??_Dbasic_istream@@QAEXXZ 0:000 ? ??_Dbasic_istringstream@@QAEXXZ And you should see that there are slight differences in the mangled names. The microsoft demangling tool decodes these as follows: Undecoration of :- "??_Dbasic_istream@@UAE@XZ" is :- "public: virtual __thiscall basic_istream::`vbase destructor'(void)" Undecoration of :- "??_Dbasic_istream@@QAEXXZ" is :- "public: void __thiscall basic_istream::`vbase destructor'(void)" The only difference in the names is towards the end. Clang is using an '@' in the 3rd from the end, which signifies an unspecified return type. Visual studio uses a 'X', which signifies a void return type. This is generated in MicrosoftCXXNameMangler::mangleFunctionType() The second issue is 6th from the end. Clang is using a 'U', Visual Studio is using a 'Q'. The 'U' signifies "virtual". My guess is that it is redundant to have this set for a vbase destructor, but I guess the reason is unimportant in that this is a difference from what Microsoft compilers are generating This is set in MicrosoftCXXNameMangler::mangleFunctionClass() It wasn't hard to follow through to see how clang came up with the mangled name that it did, but it isn't at all obvious to me what the correct fix should be. -- 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 31932] New: PIC references to __dso_handle should behave as with hidden visibility
https://llvm.org/bugs/show_bug.cgi?id=31932 Bug ID: 31932 Summary: PIC references to __dso_handle should behave as with hidden visibility Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: rol...@hack.frob.com CC: llvm-bugs@lists.llvm.org, pho...@chromium.org Classification: Unclassified When Clang emits calls to __cxa_atexit, it generates references to the symbol __dso_handle. The sole purpose of this symbol is that it have a different address in each linked module (shared library or the executable). To that end, its definition is always made with hidden visibility. So using the GOT indirection table in PIC mode just adds extra indirection overhead and an extra dynamic reloc that will always be relaxed into a simple R_*_RELATIVE. GCC emits references to __dso_handle that do not use the GOT. I have a patch to fix this, though it might need some cleanup. -- 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 31933] New: AVX512: LLVM generates poor quality code involving masks
https://llvm.org/bugs/show_bug.cgi?id=31933
Bug ID: 31933
Summary: AVX512: LLVM generates poor quality code involving
masks
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: wenzel.ja...@epfl.ch
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang/LLVM (trunk) seems to have issues generating code involving bitwise
arithmetic of AVX512-style mask registers with sizes other than 16 bits.
Consider the following two versions of a (somewhat contrived) program that
computes three masks and then ORs them together:
#include
/* Version 1: use _mm512_kor */
__m512d test1(__m512d a, __m512d b, __m512d c) {
__mmask8 m1 = _mm512_cmp_pd_mask(a, b, _CMP_LT_OQ);
__mmask8 m2 = _mm512_cmp_pd_mask(b, c, _CMP_LT_OQ);
__mmask8 m3 = _mm512_cmp_pd_mask(c, a, _CMP_LT_OQ);
__mmask8 m = _mm512_kor(_mm512_kor(m1, m2), m3);
return _mm512_mask_blend_pd(m, a, b);
}
/* Version 2: use operator| */
__m512d test2(__m512d a, __m512d b, __m512d c) {
__mmask8 m1 = _mm512_cmp_pd_mask(a, b, _CMP_LT_OQ);
__mmask8 m2 = _mm512_cmp_pd_mask(b, c, _CMP_LT_OQ);
__mmask8 m3 = _mm512_cmp_pd_mask(c, a, _CMP_LT_OQ);
__mmask8 m = m1 | m2 | m3;
return _mm512_mask_blend_pd(m, a, b);
}
Version 1 (with _mm512_kor) generates the following code (uh, oh, lots of e*x
<-> k* transitions, move with zero extend, etc.)
__Z5test1Dv8_dS_S_:
vcmplt_oqpdk0, zmm0, zmm1
kmovweax, k0
vcmplt_oqpdk0, zmm1, zmm2
kmovwecx, k0
vcmplt_oqpdk0, zmm2, zmm0
kmovwedx, k0
movzxeax, al
movzxecx, cl
kmovwk0, ecx
kmovwk1, eax
korwk0, k1, k0
movzxeax, dl
kmovwk1, eax
korwk0, k0, k1
kmovweax, k0
kmovwk1, eax
vblendmpdzmm0 {k1}, zmm0, zmm1
ret
Version 2 is better but still not ideal due to the unnecessary transitions
between mask registers and regular registers.
__Z5test2Dv8_dS_S_:
vcmplt_oqpdk0, zmm0, zmm1
kmovweax, k0
vcmplt_oqpdk0, zmm1, zmm2
kmovwecx, k0
vcmplt_oqpdk0, zmm2, zmm0
kmovwedx, k0
orcl, al
orcl, dl
kmovwk1, ecx
vblendmpdzmm0 {k1}, zmm0, zmm1
ret
What I would have expected to see is this, but it doesn't seem that Clang/LLVM
is able to generate it:
vcmplt_oqpdk0, zmm0, zmm1
vcmplt_oqpdk1, zmm1, zmm2
vcmplt_oqpdk2, zmm2, zmm0
korwk0, k0, k1
korwk0, k0, k2
vblendmpdzmm0 {k0}, zmm0, zmm1
I think that either version 1 or version 2 (or both) should. It would be great
if this could be 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 31358] Clang should support -march=armv7ve for gcc compatibility
https://llvm.org/bugs/show_bug.cgi?id=31358 Manoj Gupta changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Manoj Gupta --- Done in r294661 + r294662. llvm change: https://reviews.llvm.org/D29472 clang change: https://reviews.llvm.org/D29773 -- 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 31934] New: Functions with non-tautological enable_if conditions shouldn't be assignable to references
https://llvm.org/bugs/show_bug.cgi?id=31934 Bug ID: 31934 Summary: Functions with non-tautological enable_if conditions shouldn't be assignable to references Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: george.burgess...@gmail.com Reporter: george.burgess...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified This behavior is good: $ echo 'void foo(void) __attribute__((enable_if(false, ""))); void (*f)(void) = foo;' | $clangpp -x c++ -o/dev/null - error: cannot take address of function 'foo' because it has one or more non-tautological enable_if conditions $ This behavior is bad: $ echo 'void foo(void) __attribute__((enable_if(false, ""))); void (&f)(void) = foo;' | $clangpp -x c++ -o/dev/null - $ ...The difference being that we use *f in the good example, but &f in the bad. -- 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 31935] New: Regression: Assertion failed: (MI.hasOneMemOperand() && "Spill instruction does not have exactly one memory operand?") when building chrome/ios
https://llvm.org/bugs/show_bug.cgi?id=31935 Bug ID: 31935 Summary: Regression: Assertion failed: (MI.hasOneMemOperand() && "Spill instruction does not have exactly one memory operand?") when building chrome/ios Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified FAILED: obj/base/base/json_parser.o ../../../../llvm-build/bin/clang++ -MMD -MF obj/base/base/json_parser.o.d -DSYSTEM_NATIVE_UTF8 -DV8_DEPRECATION_WARNINGS -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=289944-2 -DCR_XCODE_VERSION=0810 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBASE_IMPLEMENTATION -I../.. -Igen -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fcolor-diagnostics -arch arm64 -Wall -Werror -Wextra -Wundeclared-selector -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.1.sdk -stdlib=libc++ -miphoneos-version-min=9.0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wno-char-subscripts -Wexit-time-destructors -Wexit-time-destructors -O2 -fno-threadsafe-statics -fvisibility-inlines-hidden -std=c++11 -fno-rtti -fno-exceptions -c ../../base/json/json_parser.cc -o obj/base/base/json_parser.o Assertion failed: (MI.hasOneMemOperand() && "Spill instruction does not have exactly one memory operand?"), function extractSpillBaseRegAndOffset, file /Users/thakis/src/llvm-rw/lib/CodeGen/LiveDebugValues.cpp, line 331. Stack dump: 0.Program arguments: /Users/thakis/src/llvm-build/bin/clang-3.8 -cc1 -triple arm64-apple-ios9.0.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -disable-free -main-file-name json_parser.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -masm-verbose -target-cpu cyclone -target-feature +neon -target-feature +crypto -target-feature +zcm -target-feature +zcz -target-abi darwinpcs -target-linker-version 274.1 -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=lldb -coverage-notes-file /Users/thakis/src/chrome/src/out/Release-iphoneos/obj/base/base/json_parser.gcno -resource-dir /Users/thakis/src/llvm-build/bin/../lib/clang/5.0.0 -dependency-file obj/base/base/json_parser.o.d -MT obj/base/base/json_parser.o -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS10.1.sdk -D SYSTEM_NATIVE_UTF8 -D V8_DEPRECATION_WARNINGS -D NO_TCMALLOC -D DISABLE_NACL -D CHROMIUM_BUILD -D FIELDTRIAL_TESTING_ENABLED -D CR_CLANG_REVISION=289944-2 -D CR_XCODE_VERSION=0810 -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D _FORTIFY_SOURCE=2 -D NDEBUG -D NVALGRIND -D DYNAMIC_ANNOTATIONS_ENABLED=0 -D BASE_IMPLEMENTATION -I ../.. -I gen -stdlib=libc++ -O2 -Wall -Werror -Wextra -Wundeclared-selector -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wno-char-subscripts -Wexit-time-destructors -Wexit-time-destructors -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/thakis/src/chrome/src/out/Release-iphoneos -ferror-limit 19 -fmessage-length 0 -fvisibility hidden -fvisibility-inlines-hidden -stack-protector 1 -stack-protector-buffer-size 4 -fallow-half-arguments-and-returns -fblocks -fno-rtti -fno-threadsafe-statics -fobjc-runtime=ios-9.0.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o obj/base/base/json_parser.o -x c++ ../../base/json/json_parser.cc 1. parser at end of file 2.Code generation 3.Running pass 'Function Pass Manager' on module '../../base/json/json_parser.cc'. 4.Running pass 'Live DEBUG_VALUE analysis' on function '@_ZN4base8internal10JSONParser16ConsumeStringRawEPNS1_13StringBuilderE' clang-3.8: error: unable to execute command: Abort trap: 6 clang-3.8: error: clang frontend co
[llvm-bugs] [Bug 31936] New: Low-quality error message using __declspec without -fms-extensions
https://llvm.org/bugs/show_bug.cgi?id=31936 Bug ID: 31936 Summary: Low-quality error message using __declspec without -fms-extensions Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: efrie...@codeaurora.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified C Testcase: __declspec(noreturn) int f(); Error message: :1:26: error: parameter named 'f' is missing __declspec(noreturn) int f(); ^ :1:30: error: expected function body after function declarator __declspec(noreturn) int f(); ^ 2 errors generated. clang is trying to parse this as a old-style C function definition, which leads to an error message which is difficult to understand. -- 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 31937] New: llvm.org/llvm/bindings/go/llvm is not Go package
https://llvm.org/bugs/show_bug.cgi?id=31937 Bug ID: 31937 Summary: llvm.org/llvm/bindings/go/llvm is not Go package Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: lin90...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I'm trying to install LLVM Go bindings following below instruction. https://llvm.org/svn/llvm-project/llvm/trunk/bindings/go/README.txt However, `go get` command fails with 'unrecognized import path' error. `go get` needs meta tag to recognize Go packages, but https://llvm.org/llvm/bindings/go/llvm?go-get=1 does not provide it. My environment is - macOS 10.12.3 - Go 1.7.5 Below is a log for this issue. $ go get -v -d llvm.org/llvm/bindings/go/llvm Fetching https://llvm.org/llvm/bindings/go/llvm?go-get=1 Parsing meta tags from https://llvm.org/llvm/bindings/go/llvm?go-get=1 (status code 404) package llvm.org/llvm/bindings/go/llvm: unrecognized import path "llvm.org/llvm/bindings/go/llvm" (parse https://llvm.org/llvm/bindings/go/llvm?go-get=1: no go-import meta tags) -- 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 31938] New: libc++ declares basic_string constructors with non-deducible types
https://llvm.org/bugs/show_bug.cgi?id=31938
Bug ID: 31938
Summary: libc++ declares basic_string constructors with
non-deducible types
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
The standard says:
template,
class Allocator = allocator>
class basic_string {
using value_type = typename traits::char_type;
// ...
basic_string(const charT* s, const Allocator& a = Allocator());
};
libc++ actually chooses to declare the constructor as
basic_string(const value_type* s, const Allocator& a = Allocator());
The implicit deduction guides from class template argument deduction make what
was previously an implementation detail visible:
std::basic_string s = "foo"; // error, can't deduce charT.
The constructor in question is in the libc++ DSO, but fortunately it looks like
fixing this will not result in an ABI break.
--
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 31939] New: LLD doesn't link sanitizer runtimes in C++ link correctly
https://llvm.org/bugs/show_bug.cgi?id=31939
Bug ID: 31939
Summary: LLD doesn't link sanitizer runtimes in C++ link
correctly
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: chandl...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Here are steps to reproduce:
% cat test.cpp
#include
int main() {
free(malloc(42));
}
% ~/bin/clang++ -fsanitize=address -fuse-ld=lld -o test test.cpp -v
clang version 5.0.0 (trunk 292694) (llvm/trunk 292757)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/chandlerc/bin
Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
"/home/chandlerc/installs/llvm-2017-01-22/bin/clang-5.0" -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb
-resource-dir /home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0
-internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3
-internal-isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/x86_64-pc-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/backward
-internal-isystem /usr/local/include -internal-isystem
/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/chandlerc/src/llvm.git/build
-ferror-limit 19 -fmessage-length 283 -fsanitize=address
-fsanitize-blacklist=/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/asan_blacklist.txt
-fno-assume-sane-operator-new -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-dc73b2.o -x c++
test.cpp
clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/backward
/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/include
/usr/include
End of search list.
"/home/chandlerc/bin/ld.lld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o test
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/crtbegin.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../lib64
-L/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../.. -L/lib -L/usr/lib
-whole-archive
/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/lib/linux/libclang_rt.asan-x86_64.a
-no-whole-archive
--dynamic-list=/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/lib/linux/libclang_rt.asan-x86_64.a.syms
-whole-archive
/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
-no-whole-archive
--dynamic-list=/home/chandlerc/installs/llvm-2017-01-22/bin/../lib64/clang/5.0.0/lib/linux/libclang_rt.asan_cxx-x86_64.a.syms
/tmp/test-dc73b2.o -lstdc++ -lm --no-as-needed -lpthread -lrt -lm -ldl -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/crtend.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../lib64/crtn.o
% nm test | grep malloc
0051f5e8 b _ZN14__interception11real_mallocE
00521648 b _ZN14__interception17real_malloc_statsE
00521618 b _ZN14__interception23real_malloc_usable_sizeE
0022d660 t
_ZN6__asan11asan_mallocEmPN11__sanitizer18BufferedStackTraceE
0022d8c0 t _ZN6__asan23asan_malloc_usable_sizeEPKvmm
005228e0 b _ZN6__asanL19malloc_context_sizeE
00522d90 b _ZN6__asanL19max_malloced_memoryE
00238670 t __asan_stack_malloc_0
00238990 t __asan_stack_malloc_1
0023abf0 t __asan_stack_malloc_10
00238ce0 t __asan_stack_malloc_2
00239070 t __asan_stack_malloc_3
00239450 t __asan_stack_malloc_4
002398e0 t __asan_stack_malloc_5
00239e90 t __asan_stack_malloc
[llvm-bugs] [Bug 31940] New: void llvm::SelectionDAGBuilder::visitInlineAsm(llvm::ImmutableCallSite): Assertion `ConstraintID != InlineAsm::Constraint_Unknown && "Failed to convert memory constraint c
https://llvm.org/bugs/show_bug.cgi?id=31940 Bug ID: 31940 Summary: void llvm::SelectionDAGBuilder::visitInlineAsm(llvm::Immuta bleCallSite): Assertion `ConstraintID != InlineAsm::Constraint_Unknown && "Failed to convert memory constraint code to constraint id."' failed Product: libraries Version: 3.8 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: compn...@compnerd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17969 --> https://llvm.org/bugs/attachment.cgi?id=17969&action=edit reduced.c -- 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
