[llvm-bugs] [Bug 43686] New: clang handles differently signed overflow depending on variable constness and its storage
https://bugs.llvm.org/show_bug.cgi?id=43686
Bug ID: 43686
Summary: clang handles differently signed overflow depending on
variable constness and its storage
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ki.s...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Godbolt: https://godbolt.org/z/2uqkzB
The first one, with i32_max int on stack prints "is 0" and returns 0:
```
int int_test() {
int i32_max = std::numeric_limits::max();
int res = i32_max + 3;
printf("res %d < i32_max %d is %d\n", res, i32_max, (int)(res < i32_max));
// ... is 0
return (int)(res < i32_max); // returns 0
}
---
int_test(): # @int_test()
push rax
mov edi, offset .L.str
mov esi, -2147483646
mov edx, 2147483647
xor ecx, ecx
xor eax, eax
call printf
xor eax, eax
pop rcx
ret
```
The second function, with i32_max const int on stack prints "is 1" and returns
1:
```
int const_int_test() {
const int i32_max = std::numeric_limits::max();
int res = i32_max + 3;
printf("res %d < i32_max %d is %d\n", res, i32_max, (int)(res < i32_max));
// ... is 1
return (int)(res < i32_max); // returns 1
}
---
const_int_test(): # @const_int_test()
push rax
mov edi, offset .L.str
mov esi, -2147483646
mov edx, 2147483647
mov ecx, 1
xor eax, eax
call printf
mov eax, 1
pop rcx
ret
```
And in the last case, with i32_max static int, it prints "is 0" and returns 1:
```
int static_int_test() {
static int i32_max = std::numeric_limits::max();
int res = i32_max + 3;
printf("res %d < i32_max %d is %d\n", res, i32_max, (int)(res < i32_max));
// ... is 0
return (int)(res < i32_max); // return 1
}
---
static_int_test(): # @static_int_test()
push rax
mov edi, offset .L.str
mov esi, -2147483646
mov edx, 2147483647
xor ecx, ecx
xor eax, eax
call printf
mov eax, 1
pop rcx
ret
```
Also, clang warns about signed overflow only in the const int case.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43687] New: opt -loop-idiom crashing with opt: ../lib/Transforms/Scalar/LoopIdiomRecognize.cpp:1986: ... Assertion ... "Unexpected exit edges."' failed.
https://bugs.llvm.org/show_bug.cgi?id=43687 Bug ID: 43687 Summary: opt -loop-idiom crashing with opt: ../lib/Transforms/Scalar/LoopIdiomRecognize.cpp:1986: ... Assertion ... "Unexpected exit edges."' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 22676 --> https://bugs.llvm.org/attachment.cgi?id=22676&action=edit f21.ll reproducer Reproduce with: opt -S -o - f21.ll -loop-idiom Result: opt: ../lib/Transforms/Scalar/LoopIdiomRecognize.cpp:1986: bool (anonymous namespace)::LoopIdiomRecognize::recognizeBCmpLoopControlFlow(const (anonymous namespace)::LoopIdiomRecognize::CmpOfLoads &, (anonymous namespace)::LoopIdiomRecognize::CmpLoopStructure &) const: Assertion `!is_contained(ExitBlocks, CmpLoop.HeaderBrEqualBB) && is_contained(ExitBlocks, CmpLoop.HeaderBrUnequalBB) && !is_contained(ExitBlocks, CmpLoop.LatchBrContinueBB) && is_contained(ExitBlocks, CmpLoop.LatchBrFinishBB) && "Unexpected exit edges."' failed. Stack dump: 0. Program arguments: /data/repo/master/llvm/build-all-builtins/bin/opt -S -o - f21.ll -loop-idiom 1. Running pass 'Function Pass Manager' on module 'f21.ll'. 2. Running pass 'Loop Pass Manager' on function '@main' 3. Running pass 'Recognize loop idioms' on basic block '%for.body1163.1' #0 0x03ebc1e4 PrintStackTraceSignalHandler(void*) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3ebc1e4) #1 0x03eb9f0e llvm::sys::RunSignalHandlers() (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3eb9f0e) #2 0x03ebc5e8 SignalHandler(int) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3ebc5e8) #3 0x7fbae2f2f890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x7fbae19d8e97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x7fbae19da801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #6 0x7fbae19ca39a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #7 0x7fbae19ca412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #8 0x03c91232 (anonymous namespace)::LoopIdiomRecognize::detectBCmpIdiom(llvm::ICmpInst*&, llvm::CmpInst*&, llvm::LoadInst*&, llvm::LoadInst*&, llvm::SCEV const*&, llvm::SCEV const*&, llvm::SCEV const*&) const (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3c91232) #9 0x03c8c47c (anonymous namespace)::LoopIdiomRecognize::recognizeBCmp() (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3c8c47c) #10 0x03c859dc (anonymous namespace)::LoopIdiomRecognize::runOnNoncountableLoop() (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3c859dc) #11 0x03c827b7 (anonymous namespace)::LoopIdiomRecognizeLegacyPass::runOnLoop(llvm::Loop*, llvm::LPPassManager&) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3c827b7) #12 0x0315c2b2 llvm::LPPassManager::runOnFunction(llvm::Function&) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x315c2b2) #13 0x03792093 llvm::FPPassManager::runOnFunction(llvm::Function&) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3792093) #14 0x03792378 llvm::FPPassManager::runOnModule(llvm::Module&) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x3792378) #15 0x037929dd llvm::legacy::PassManagerImpl::run(llvm::Module&) (/data/repo/master/llvm/build-all-builtins/bin/opt+0x37929dd) #16 0x021506fd main (/data/repo/master/llvm/build-all-builtins/bin/opt+0x21506fd) #17 0x7fbae19bbb97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 #18 0x0213402a _start (/data/repo/master/llvm/build-all-builtins/bin/opt+0x213402a) Abort (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43688] New: optimize ctpop codegen by width and narrow ctpop intrinsic in IR
https://bugs.llvm.org/show_bug.cgi?id=43688
Bug ID: 43688
Summary: optimize ctpop codegen by width and narrow ctpop
intrinsic in IR
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Spinning this off from bug 43656:
define i32 @zpop(i8 %x) {
%z = zext i8 %x to i32
%pop = tail call i32 @llvm.ctpop.i32(i32 %z)
ret i32 %pop
}
define i32 @popz(i8 %x) {
%pop = tail call i8 @llvm.ctpop.i8(i8 %x)
%z = zext i8 %pop to i32
ret i32 %z
}
declare i8 @llvm.ctpop.i8(i8)
declare i32 @llvm.ctpop.i32(i32)
--
These are equivalent, so we should try to canonicalize them in IR. The narrow
call is likely better for vectorization and would line up with our transforms
of most math/logic ops.
But we don't have DAGCombiner and/or legalization to ensure that the narrow
call is optimized in codegen.
For example on base x86-64:
_zpop: ## @zpop
movzbl %dil, %eax
movl%eax, %ecx
shrl%ecx
andl$-43, %ecx
subl%ecx, %eax
movl%eax, %ecx
andl$858993459, %ecx## imm = 0x
shrl$2, %eax
andl$858993459, %eax## imm = 0x
addl%ecx, %eax
movl%eax, %ecx
shrl$4, %ecx
addl%eax, %ecx
andl$252645135, %ecx## imm = 0xF0F0F0F
imull $16843009, %ecx, %eax ## imm = 0x1010101
shrl$24, %eax
retq
_popz: ## @popz
movl%edi, %eax
shrb%al
andb$85, %al
subb%al, %dil
movl%edi, %eax
andb$51, %al
shrb$2, %dil
andb$51, %dil
addb%al, %dil
movl%edi, %eax
shrb$4, %al
addb%dil, %al
andb$15, %al
movzbl %al, %eax
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43525] 64-bit call site value immediate is truncated
https://bugs.llvm.org/show_bug.cgi?id=43525 David Stenberg changed: What|Removed |Added CC||david.stenb...@ericsson.com Resolution|--- |FIXED Fixed By Commit(s)||r374770 Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43656] Regression in ctpop loop vectorizer (trunk vs. llvm 9)
https://bugs.llvm.org/show_bug.cgi?id=43656 Sanjay Patel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Sanjay Patel --- (In reply to Simon Pilgrim from comment #9) > The original vectorization regression is now fixed in trunk by rL374775 > > Should we keep this ticket open to handle the zext(ctpop(zext(x))) case as > well or split it off? It's going to take more than 1 patch to get it right, so I think we better fork. Opened bug 43688. Marking this as resolved since the regression from clang 9 is gone (reopen if I got that wrong). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43689] New: [instcombine] Miscompile in visitShuffleVectorInst (transform introduces unsafe integer div/rem)
https://bugs.llvm.org/show_bug.cgi?id=43689
Bug ID: 43689
Summary: [instcombine] Miscompile in visitShuffleVectorInst
(transform introduces unsafe integer div/rem)
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: bjorn.a.petters...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Our downstream fuzzy test framework found a miscompile due to what seems to be
a bug in InstCombine.
Here is a reduced test case:
;-
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt < %s -instcombine -S -o - | FileCheck %s
; This test case was added as a reproducer for a miscompile, where instcombine
; introduced an
; srem <2 x i16> %1,
; instruction, which makes the whole srem undefined (even if we only end up
; extracting the second element in the vector).
define i16 @test1(i16 %a, i1 %cmp) {
; CHECK-LABEL: @test1(
; CHECK-NEXT:ret i16 1
;
%splatinsert = insertelement <2 x i16> undef, i16 %a, i32 0
%splat = shufflevector <2 x i16> %splatinsert, <2 x i16> undef, <2 x i32>
zeroinitializer
%t1 = select i1 %cmp, <2 x i16> , <2 x i16> %splat
%t2 = srem <2 x i16> %t1,
%t3 = extractelement <2 x i16> %t2, i32 1
ret i16 %t3
}
; This is basically a reduced version of test1 (based on what the code would
; look like after a few iterations of instcombine, just before we try to
; transform the shufflevector by doing "evaluateInDifferentElementOrder".
define <2 x i16> @test2(i16 %a, i1 %cmp) {
; CHECK-LABEL: @test2(
; CHECK-NEXT:ret <2 x i16>
;
%splatinsert = insertelement <2 x i16> undef, i16 %a, i32 0
%t1 = srem <2 x i16> %splatinsert,
%splat.op = shufflevector <2 x i16> %t1, <2 x i16> undef, <2 x i32>
%t2 = select i1 %cmp, <2 x i16> , <2 x i16> %splat.op
ret <2 x i16> %t2
}
;-
Problem is that instcombine transforms IR like this
%splatinsert = insertelement <2 x i16> undef, i16 %a, i32 0
%t1 = srem <2 x i16> %splatinsert,
%splat.op = shufflevector <2 x i16> %t1, <2 x i16> undef, <2 x i32>
into
%1 = insertelement <2 x i16> undef, i16 %a, i32 1
%2 = srem <2 x i16> %1,
which introduces an undef denominator in the srem. This makes the whole srem
undefined and we get a miscompile.
The transform above happens in InstCombiner::visitShuffleVectorInst when doing
if (isa(RHS) && canEvaluateShuffled(LHS, Mask)) {
Value *V = evaluateInDifferentElementOrder(LHS, Mask);
return replaceInstUsesWith(SVI, V);
}
I think the bug can be solved by adding some more restrictions in
canEvaluateShuffled for integer div/rem instructions.
I have a suggested patch that I'll upload in Phabricator.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43690] New: LLVM produces redundant IVs and fails to eliminate them
https://bugs.llvm.org/show_bug.cgi?id=43690
Bug ID: 43690
Summary: LLVM produces redundant IVs and fails to eliminate
them
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: d.malju...@yandex.ru
CC: llvm-bugs@lists.llvm.org
Created attachment 22677
--> https://bugs.llvm.org/attachment.cgi?id=22677&action=edit
Example
It looks like SCEVExpander can create redundant IVs when expanding some SCEV
because
1) It tries to expand SCEV that is identical to that of the IV PHI node, but
the IV is not in a canonical form. The PHI is not reused because it's never
added to ExprToValueMap (only to ValueToExpr), and since it's not in canonical
form (and expander is in canonical mode), it creates additional IV.
I.e. when trying to expand {1,+,1}<%for.body> with the same IV, it'll
create additional IV {0,+,1}<%for.body> + add+1 IR instruction.
See the attached IR for such an example.
2) If SCEVExpander is not in canonical mode, it deals with case above, however
it results in the similar problem in the opposite situation, since it doesn't
reuse addrec expressions in non-canonical mode:
https://github.com/llvm/llvm-project/blob/5c3bc3c930d3993a2c5f581112c18a9eb0ba6838/llvm/lib/Analysis/ScalarEvolutionExpander.cpp#L1787
After such redundant IVs are generated, llvm fails to get rid of them (as
demonstrated by running opt -O3 on the attached IR).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43691] New: InlineSpiller fails to rematerialize zero-idioms/allones-idioms on X86.
https://bugs.llvm.org/show_bug.cgi?id=43691
Bug ID: 43691
Summary: InlineSpiller fails to rematerialize
zero-idioms/allones-idioms on X86.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: andrea.dibia...@gmail.com
CC: llvm-bugs@lists.llvm.org, quentin.colom...@gmail.com
Example:
```
_m128i all_zeroes(__m128i *Y, __m128 *Z, unsigned B) {
__m128i X = (__m128i)(__v4si) { 0, 0, 0, 0 };
__m128i Phi = *Y;
while (B) {
__asm volatile (""::: "xmm0", "xmm1",
"xmm2", "xmm3",
"xmm4", "xmm5",
"xmm6", "xmm7",
"xmm8", "xmm9",
"xmm10", "xmm11",
"xmm12", "xmm13",
"xmm14", "memory");
Phi = (__m128i) *Z | _mm_cmpeq_epi32(Phi, X);
--B;
}
return Phi;
}
```
Compile with -mavx on a generic linux x86_64.
This is the loop body (`-mavx` -- on a generic x86_64 linux triple):
```
.LBB0_1:
vpcmpeqd.LCPI0_0, %xmm15, %xmm0
vpor(%rsi), %xmm0, %xmm15
addl$-1, %edx
jne .LBB0_1
```
.LCPI0_0 is a constant pool entry for a zero vector:
```
.zero 16
```
You will see that the compiler emits a needless constant pool entry for a zero
vector. That entry is then loaded in the loop body.
It is not a good idea to generate constant pool entries for zero vectors
because they are cheap to rematerialize. All modern x86 processors are able to
optimize out zero/all-ones idioms at register renaming stage. All those idioms
are also treated as dependency-breaking instructions, which means that they
don't have any input register dependency).
In this particular example, the InlineSpiller fails to rematerialize an
AVX_SET0 pseudo. So we end up with a constant pool entry for a zero vector, and
a folded-load in the vector compare instruction.
A full test case for both zero-idioms and allones-idioms can be found here at
this link: https://godbolt.org/z/h9UrVR
You can see how GCC generates a zero-idiom VPXOR to rematerialize the zero
vector within the loop. No load from constant pool is required. Interestingly
GCC is not smart enough to realize that all-ones idioms can be treated
specially.
```
.L3:
vpxor %xmm1, %xmm1, %xmm1
vpcmpeqd%xmm1, %xmm15, %xmm15
vpor(%rsi), %xmm15, %xmm15
subl$1, %edx
jne .L3
```
(Some of the) Affected PSEUDO opcodes are:
V_SET0
V_SETALLONES
AVX_SET0
AVX1_SETALLONES
AVX2_SETALLONES
AVX512_128_SET0
AVX512_256_SET0
AVX512_512_SET0
Here are the definitions from X86GenInstrInfo.inc:
```
{ 246,1, 1, 0, 2,
0|(1ULL<, 8> Ops;
MIBundleOperands::VirtRegInfo RI =
MIBundleOperands(MI).analyzeVirtReg(VirtReg.reg, &Ops);
if (!RI.Reads)
return false;
```
RI.Reads is always false for all those pseudos. That makes sense because
zero-idioms and all-ones idioms don't have register dependencies (i.e. it is
normal not to have register reads).
The check on the presence of register reads is surprisingly restrictive.
It is also unclear to me why it is needed at all. If somebody knows the reason
why we need that check then I'd be very happy to know. We definitely need a
code comment for it! (it would make life easier to people that want to study
that method).
According to `git blame`, that check was added by the following commit:
```
commit 296acbfe4f91fd80ffc64c54be69abec388c7017
Author: Patrik Hagglund
Date: Mon Sep 1 11:04:07 2014 +
Fix in InlineSpiller to make the rematerilization loop also consider
implicit uses of the whole register when a sub register is defined.
Now the same iterator is used in the rematerilization loop as in the
spill loop later.
Patch provided by Mikael Holmen.
This fix was proposed and reviewed by Quentin Colombet,
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076135.html.
Unfortunately, this error in the rematerilization code has only been
seen in a large test case for an out-of-tree target, and is probably
hard to reproduce on an in-tree target. Therefore, no testcase is
provided.
llvm-svn: 216873
```
Note: the link to the llvmdev thread mentioned by that message is probably
wrong. I am assuming that this is the correct reference:
http://lists.llvm.org/pipermail/llvm-dev/2014-August/075794.html
It is easy to workaround this issue. For example, we can treat Pseudo
instructions specially: if a pseudo is marked as rematerializable, then we can
probably ignore the register reads check.
--
You are receiving this mail because:
You are on the CC list for the bug._
[llvm-bugs] [Bug 43692] New: [IndVarSimplify] Functional change with -DLLVM_ENABLE_ASSERTIONS=OFF
https://bugs.llvm.org/show_bug.cgi?id=43692 Bug ID: 43692 Summary: [IndVarSimplify] Functional change with -DLLVM_ENABLE_ASSERTIONS=OFF Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 22678 --> https://bugs.llvm.org/attachment.cgi?id=22678&action=edit reduced testcase opt -mtriple=s390x-linux-gnu -mcpu=z14 tc_asserts_FC.ll -O3 Depending on -DLLVM_ENABLE_ASSERTIONS= OFF or ON, this gives a different output. After Induction Variable Simplification: with asserts <> no asserts zext | sext icmp ne | icmp slt -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43693] New: Clang++ segfaults when compiling our code
https://bugs.llvm.org/show_bug.cgi?id=43693 Bug ID: 43693 Summary: Clang++ segfaults when compiling our code Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: benso...@llnl.gov CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22680 --> https://bugs.llvm.org/attachment.cgi?id=22680&action=edit Files requested in error message Hi, Recent clangs have been segfaulting on OSX when compiling our code, https://github.com/llnl/lbann. It seems to be an issue in one translation unit in particular, "src/layers/loss/cross_entropy.cpp". I've followed the instructions at the end of the segfault message and attached a tarball, "clang-cross-entropy-issue.tar.xz", with the requested files as well as a log of the output. This was reproduced yesterday with a clang I build from the head of "master". Please let me know if there's anything else you need from me. Any help would be much appreciated. Cheers, Tom -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43694] New: static members of template class aren't initialized in order
https://bugs.llvm.org/show_bug.cgi?id=43694 Bug ID: 43694 Summary: static members of template class aren't initialized in order Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: vincent.h...@higaski.at CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22681 --> https://bugs.llvm.org/attachment.cgi?id=22681&action=edit Minimal example -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43685] Constexpr new: uncatched UB in constant context
https://bugs.llvm.org/show_bug.cgi?id=43685 David Blaikie changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from David Blaikie --- (In reply to Alexander Zaitsev from comment #3) > I don't know a lot about internals and how it can be detected (I trust you > that checking something like that is undetectable). But if it's undefined > behavior in C++ standard it shall lead to compile error in constexpr (AFAIK > constexpr context cannot have UB inside and all code with UB shall lead to > compile error). So the wording in C++17 is as follows: 8.20 [expr.const] p2 "An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine (4.6), would evaluate one of the following expressions:" ... "an operation that would have undefined behavior as specified in Clauses 4 through 19 of this document" That specifically does not include Clause 20, which is where the standard library is defined. So I believe the compiler behavior you're observing is conforming, though the code is non-portable (as it's /possible/ that some other implementation might have UB (as specified in Clauses 4 through 19) on these codepaths - but it's not required that they do). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43694] static members of template class aren't initialized in order
https://bugs.llvm.org/show_bug.cgi?id=43694 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Richard Smith --- There is no defined initialization order for implicitly instantiated variables. See http://eel.is/c++draft/basic.start.dynamic#1.sentence-1 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43695] New: clang fatal error using __declspec(allocator) with -O3 : "error in backend: invalid symbol redefinition"
https://bugs.llvm.org/show_bug.cgi?id=43695
Bug ID: 43695
Summary: clang fatal error using __declspec(allocator) with -O3
: "error in backend: invalid symbol redefinition"
Product: new-bugs
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: sylvain.a...@ubisoft.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
I discovered this bug with clang 9.0.0, under windows. It seems to be there in
trunk too.
Note that removing the _declspec(allocator), the expression in the alloc() call
parameter, or even the call to f2() will compile.
F:\>type test.cpp
__declspec(allocator) void *alloc(unsigned int size);
void f2();
void f1(unsigned int *size_ptr) {
void *hg = alloc(size_ptr ? *size_ptr : 1UL);
f2();
}
F:\>
F:\>
F:\>clang++.exe -cc1 -S -x86-asm-syntax=intel -debug-info-kind=limited
-fms-extensions -O3 -x c++ test.cpp
fatal error: error in backend: invalid symbol redefinition
Stack dump:
0. Program arguments: clang++.exe -cc1 -S -x86-asm-syntax=intel
-debug-info-kind=limited -fms-extensions -O3 -x c++ test.cpp
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'test.cpp'.
4. Running pass 'X86 Assembly Printer' on function '@"?f1@@YAXPEAI@Z"'
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 3082] loop-extractor infinite memory usage
https://bugs.llvm.org/show_bug.cgi?id=3082 Ehud Katz changed: What|Removed |Added Attachment #2214|0 |1 is obsolete|| Assignee|unassignedb...@nondot.org |ehudk...@gmail.com CC||ehudk...@gmail.com Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #5 from Ehud Katz --- Created attachment 22682 --> https://bugs.llvm.org/attachment.cgi?id=22682&action=edit new_testcase Still reproducible in LLVM version 9.0 and today's trunk. I have attached an updated version of the testing BC. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43669] Segfault when compiling boot/beast when openmp is enabled
https://bugs.llvm.org/show_bug.cgi?id=43669 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Alexey Bataev --- Also, tried to compile it with clang 10.0 on wandbox, was unable to reproduce. Seems to me, the bug is a duplicate for Bug 43175 *** This bug has been marked as a duplicate of bug 43175 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43695] clang fatal error using __declspec(allocator) with -O3 : "error in backend: invalid symbol redefinition"
https://bugs.llvm.org/show_bug.cgi?id=43695 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- Yes, the key thing here is -O3, which raises the tail duplication threshold, resulting in the same label being emitted twice. I discussed a plan to fix this with Amy yesterday. In the meantime, I might try to put together a workaround to make this not be a fatal error. Missing one heap allocation site won't be the end of the world. *** This bug has been marked as a duplicate of bug 43479 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43696] New: wasm-ld satisfies weak external from archive
https://bugs.llvm.org/show_bug.cgi?id=43696
Bug ID: 43696
Summary: wasm-ld satisfies weak external from archive
Product: lld
Version: unspecified
Hardware: Other
OS: other
Status: NEW
Severity: enhancement
Priority: P
Component: wasm
Assignee: unassignedb...@nondot.org
Reporter: dan433...@gmail.com
CC: llvm-bugs@lists.llvm.org, s...@chromium.org
wasm-ld (in LLVM 9.0) is pulling in symbols from an archive to satisfy weak
external references, which is different from what ELF linkers do, and precludes
a common use case.
Consider this testcase:
```c
#include
extern int x __attribute__((weak));
int main(void) {
if (&x) {
printf("we have x: %d\n", x);
}
return 0;
}
```
This shouldn't cause `x` to be linked by itself, because `x` is weak, even if
`x` is available in an archive library. But if I create an archive library
containing this:
```c
int x = 42;
```
then `x` does get linked.
With the above snippets in a.c and b.c respectively, this command-line
reproduces the issue with wasi-sdk (clang configured to target wasm32 by
default):
$ clang -c b.c && llvm-ar crs b.a b.o && clang a.c b.a -Wl,-y,x
/tmp/a-5e48c9.o: reference to x
b.a: lazy definition of x
For comparison, on an ELF target, I get this:
$ clang -c b.c && llvm-ar crs b.a b.o && clang a.c b.a -Wl,-y,x
/tmp/a-4c66f3.o: reference to x
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41049] [ARM64] Debugging Arm64 debug binary gives memory access error when accessing local variables
https://bugs.llvm.org/show_bug.cgi?id=41049 Tom Tan changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18295 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-17 Type: Bug New issue 18295 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18295 Detailed Report: https://oss-fuzz.com/testcase?key=5100991795429376 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcef8d6ec0 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201910140329:201910150335 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5100991795429376 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43697] New: Merge r375077 into the 9.0 branch : [lld][WebAssembly] Fix for weak references to data symbols in archives
https://bugs.llvm.org/show_bug.cgi?id=43697 Bug ID: 43697 Summary: Merge r375077 into the 9.0 branch : [lld][WebAssembly] Fix for weak references to data symbols in archives Product: new-bugs Version: 9.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: s...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 43360 Is it OK to merge the following revision(s) to the 9.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=43360 [Bug 43360] [meta] 9.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43696] wasm-ld satisfies weak external from archive
https://bugs.llvm.org/show_bug.cgi?id=43696 Sam Clegg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Sam Clegg --- I send a merge request to get this fix backported to 9.0: https://bugs.llvm.org/show_bug.cgi?id=43697 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34490] r312318 causing null dereference crash
https://bugs.llvm.org/show_bug.cgi?id=34490 Ehud Katz changed: What|Removed |Added Fixed By Commit(s)||r313870 CC||ehudk...@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Ehud Katz --- Fixed in r313870. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
