[llvm-bugs] [Bug 25502] New: 'scan-build ./configure' loops on building 'conftest1.c/conftest2.c'
https://llvm.org/bugs/show_bug.cgi?id=25502 Bug ID: 25502 Summary: 'scan-build ./configure' loops on building 'conftest1.c/conftest2.c' Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: hoes.maar...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15271 --> https://llvm.org/bugs/attachment.cgi?id=15271&action=edit The 'conftest1.c' and 'conftest2.c' ./configure testcases I'm trying to analyze a certain project [1] with the clang-analyzer. But at a certain step [2] during 'scan-build ./configure', the command appears to loop. This step is trying to compile 2 small C testcases, 'conftest1.c' and 'conftest2.c' (which Ive included in the attachment), and the executed commandline is this : /bin/sh ./libtool --mode=compile /usr/local/bin/../libexec/ccc-analyzer conftest1.c -c -o conftest1.lo Running this on the command line gives me endless lines of this : Waiting for -c.o.lock to be removed Waiting for -c.o.lock to be removed Waiting for -c.o.lock to be removed If I just run './configure' without scan-build, the configure finishes quite fast and as expected. I'm running a recent svn version (r252789) of llvm/clang/scan-build on Fedora 23. [1] Hyperion https://github.com/hercules-390/hyperion [2] checking whether getopt wrapper kludge is necessary... -- 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 25503] New: The instcombine pass cause 4 piglit/mesa tests to fail in ppc64le
https://llvm.org/bugs/show_bug.cgi?id=25503 Bug ID: 25503 Summary: The instcombine pass cause 4 piglit/mesa tests to fail in ppc64le Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: oded.gab...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15272 --> https://llvm.org/bugs/attachment.cgi?id=15272&action=edit LLVM IR for original code, with instcombine and vmaxfp Hi, I'm working on enabling graphics (OpenGL) on ppc64le arch. This is done through the llvmpipe driver in the mesa library. The llvmpipe driver converts TGSI shader code into LLVM IR, by calling LLVM API functions that build the IR, then call LLVM API to compile it as JIT function and then call that function when necessary (multiple times). To test mesa, we use another open source library called piglit, which contains thousands of tests. Currently, I'm working on tests that fail on ppc64le but pass on x86-64 (Haswell). I started with almost 600 such tests and now I'm down to about 10. I now found that out of those 10, 4 tests can succeed if I disable the use of the instcombine pass. I made no other change in mesa, piglit or llvm code. This means that the generated LLVM IR is the same (with or without the instcombine pass), but the generated assembly is different. Unfortunately, the generated assembly of graphic shaders is quite large (just under 3400 assembly commands). That's why it is very difficult for me to compare the generated assembly with this pass and without - the generated assembly is very different. I tried also to produce a "short" standalone IR file and reproduce the problem with that, but to no avail. I have two other findings I'd like to point out: 1. I thought that in the meantime, I could disable this pass in llvmpipe and make those 4 tests pass. Unfrotunately, I found out that even though it fixes those 4 tests, it causes a regression in about 30 other tests - which is very weird and something I find distributing. 2. There is another option to make those 4 tests pass, and that is to disable use of the Altivec vmaxfp intrinsic (and instead use a couple of generic add/sub/shift IR commands). Now, I don't know why, but that fixes those 4 tests. Of course, that intrinsic is used in many many tests (almost all of them), and most of the tests pass, so the problem is not in this Altivec intrinsic itself, but probably in some combination of it and other things. I have attached 6 files: - LLVM IR and generated assembly files for original code, with instcombine and vmaxfp - LLVM IR and generated assembly files for modified code, without instcombine but with vmaxfp - LLVM IR and generated assembly files for modified code, with instcombine but without vmaxfp Those files above were generated by mesa (see below on how to re-create them). Because the bug is in a certain variant of the fragment shader, I removed all the other shader codes from the above files because it is not relevant. Therefore, they are shorter then the original dumps. In addition, I would like to post here the steps to re-create this setup on a POWER8, ppc64le machine. I'm using RHEL 7.2 internal release, but RHEL 7.1LE or Fedora 21/22 ppc64le can be used as well. The important thing is that you need a desktop GUI, such as GNOME, because you need xserver to run. 1. Clone LLVM, mesa and piglit repos: 1.1 git clone http://llvm.org/git/llvm.git 1.2 git clone git://anongit.freedesktop.org/mesa/mesa 1.3 git://anongit.freedesktop.org/git/piglit 1.4 export LLVM_ROOT= 1.5 export MESA_ROOT= 1.6 export PIGLIT_ROOT= 1.7 export LIBGL_ALWAYS_SOFTWARE=1 2. Build LLVM 2.1 mkdir ~/myllvmbuild ; cd ~/myllvmbuild 2.2 $LLVM_ROOT/configure --disable-dependency-tracking --prefix=$HOME/.local --with-extra-ld-options=-Wl,-Bsymbolic,--default-symver --enable-targets=host --enable-bindings=none --enable-debug-runtime --enable-jit --enable-shared --enable-optimized --disable-clang-arcmt --disable-clang-static-analyzer --disable-clang-rewriter --disable-assertions --disable-docs --disable-libffi --disable-terminfo --disable-timestamps 2.3 make -j8 ; make install 3. Build mesa 3.1 mkdir ~/mesa_debug_build ; cd ~/mesa_debug_build 3.2 $MESA_ROOT/autogen.sh --disable-dependency-tracking --prefix=$HOME/.local --enable-selinux --enable-osmesa --with-dri-driverdir=$HOME/.local/lib/dri --enable-egl --disable-gles1 --enable-gles2 --disable-xvmc --disable-dri3 --with-egl-platforms=x11,drm --enable-shared-glapi --enable-gbm --disable-opencl --enable-glx-tls --enable-texture-float=yes --enable-gallium-llvm --enable-llvm-shared-libs --enable-dri --with-gallium-drivers=svga,swrast --with-dri-drivers=swrast --with-llvm-prefix=$HOM
[llvm-bugs] [Bug 25504] New: Inline asm Instruction line with PTR inside. Accept register as memory.
https://llvm.org/bugs/show_bug.cgi?id=25504 Bug ID: 25504 Summary: Inline asm Instruction line with PTR inside. Accept register as memory. Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ziv.iz...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Instruction line with PTR inside. Accept register as memory. For example: andpd xmm1,xmmword ptr xmm1 xmm1 is a register name and not a memory name. -- 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 25505] New: [Polly] Loop invariant code motion, structures and non-power-of-two types cause miscompile
https://llvm.org/bugs/show_bug.cgi?id=25505
Bug ID: 25505
Summary: [Polly] Loop invariant code motion, structures and
non-power-of-two types cause miscompile
Product: Projects
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Polly
Assignee: polly-...@googlegroups.com
Reporter: tob...@grosser.es
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
With 252860 Polly currently miscompiles LNT MultiSource/Applications/obsequi.
The miscompilation is in hash.c:hashlookup at the last
LOOKUP_ENTRY(g_flipVH_hashkey) call.
Two issues I see:
1) We hoist loads from Non-Affine Region Statements. For such statements we
do not necessarily know that loads will be executed, hence hoisting them
may cause segfaults (may not be part of the issue here)
2) When creating access locations we generate incorrect code in case number of
bytes and actual allocation size of a type do not match. Below is a patch that
might fix this, but it has not yet been properly tested and is possibly
incomplete.
@@ -171,6 +171,18 @@ Value *IslExprBuilder::createAccessAddress(isl_ast_expr
*Expr) {
Builder.CreateMul(IndexOp, DimSize, "polly.access.mul." + BaseName);
}
+ auto &DL =
+ Builder.GetInsertBlock()->getParent()->getParent()->getDataLayout();
+ unsigned int StorageSize = DL.getTypeAllocSize(SAI->getElementType());
+ unsigned int ElementSize = SAI->getElemSizeInBytes();
+ if (!SAI->getElementType()->isPointerTy() && ElementSize != StorageSize) {
+Value *ElementValue = Builder.getInt8(ElementSize);
+Value *StorageValue = Builder.getInt8(StorageSize);
+ElementValue = Builder.CreateSExt(ElementValue, IndexOp->getType());
+StorageValue = Builder.CreateSExt(StorageValue, IndexOp->getType());
+IndexOp = Builder.CreateMul(IndexOp, ElementValue);
+IndexOp = Builder.CreateSDiv(IndexOp, StorageValue);
+ }
This patch prevents us from segfaulting for this test case.
3) Even with this patch applied, we still miscompile the test case. I have no
idea what is going on.
I need to move to other stuff know, but if someone could have a look that would
be appreciated.
--
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 25506] New: macro string concatenation does not generate the expected result in an assembly macro
https://llvm.org/bugs/show_bug.cgi?id=25506 Bug ID: 25506 Summary: macro string concatenation does not generate the expected result in an assembly macro Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: oliv...@labapart.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When the macro '#define CONCAT(a, b) CONCAT2(a, b)' is declared, Clang inserts the space between ',' and 'b' in the result when this macro is used in an assembly macro definition (ie: '.macro'). For instance the call CONCAT(a, b) in an assembly macro would generate the string 'a b' instead of 'ab'. This use case is actually present in newlib source code (https://sourceware.org/newlib/). GCC produces the expected result. If I replace '#define CONCAT(a, b) CONCAT2(a, b)' by '#define CONCAT(a, b) CONCAT2(a,b)' then the expected result is generated. Here is the example: - hello.S - /* ANSI concatenation macros. */ #define CONCAT(a, b) CONCAT2(a, b) #define CONCAT2(a, b) a##b #ifndef __USER_LABEL_PREFIX__ #error __USER_LABEL_PREFIX__ not defined #endif #define SYM(x) CONCAT (__USER_LABEL_PREFIX__, x) .text .align bl SYM(setjmp) .macro FUNC_START name .text .align 2 .globl SYM (\name) SYM (\name): .endm FUNC_START setjmp bx lr -- $ clang-3.8 -target arm-none-eabi -c hello.S :3:18: error: unexpected token in directive .globl _ setjmp ^ hello.S:22:2: note: while in macro instantiation FUNC_START setjmp ^ :4:9: error: unexpected token in argument list _ setjmp: ^ hello.S:22:2: note: while in macro instantiation FUNC_START setjmp ^ -- 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 25507] New: [Polly] Unnecessarily complicated schedule
https://llvm.org/bugs/show_bug.cgi?id=25507
Bug ID: 25507
Summary: [Polly] Unnecessarily complicated schedule
Product: Projects
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Polly
Assignee: polly-...@googlegroups.com
Reporter: l...@meinersbur.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15279
--> https://llvm.org/bugs/attachment.cgi?id=15279&action=edit
Extract from MultiSource/Benchmark/Ptrdist/bc/number.c
$ clang loopschedule.c -c -O3 -mllvm -polly -mllvm -debug -mllvm
-debug-only=polly-ast -mllvm -polly-process-unprofitable
emits the following schedule for the loop "while.body => while.end"
for (int c0 = 0; c0 < min(n2, n1); c0 += 1)
Stmt_while_body(c0);
if (n1 <= 0) {
Stmt_while_body(0);
} else if (n2 <= 0)
Stmt_while_body(0);
Context:
[n2, n1] -> { : n2 >= -2147483648 and n2 <= 2147483647 and n1 >=
-2147483648 and n1 <= 2147483647 }
Assumed Context:
[n2, n1] -> { : }
Boundary Context:
[n2, n1] -> { : }
Statements
Stmt_while_body
Domain :=
[n2, n1] -> { Stmt_while_body[i0] : i0 >= 0 and i0 <= -1 + n1
and i0 <= -1 + n2; Stmt_while_body[0] : n1 <= 0 or (n2 <= 0 and n1 >= 1) };
The initial loop condition is hoisted outside of the scop, i.e
if ((n1 > 0) && (n2 > 0)) {
// Scop
}
1) The generated schedule has two conditions (n1 <= 0) and (n2 <= 0) that are
never evaluated code, i.e. 2/3 of the generated code is effectively dead.
2) After passing the hoisted initial condition, the BasicBlock while.body must
be executed at least once before the condition is checked again. Still, CodeGen
inserts a second initial check into "polly.loop_if". It results into an
additional branch that is not optimized away by later LLVM passes and
potentially "undef" to appear after -mem2reg.
We might analyze the hoisted condition to translate into additional assumptions
(Here: n1 > 0 && n2 > 0). Unfortunately, there is no LLVM analysis to tell the
the possible range of a value.
--
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 25508] New: Incorrect __USER_LABEL_PREFIX__ for the triple arm-none-*eabi*
https://llvm.org/bugs/show_bug.cgi?id=25508 Bug ID: 25508 Summary: Incorrect __USER_LABEL_PREFIX__ for the triple arm-none-*eabi* Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: oliv...@labapart.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Symbols are not prefixed by '_' (ie: __USER_LABEL_PREFIX__ = '_') for ARM EABI. >From the document 'ELF for ARM architecture document', 4.5.4 Symbol names A symbol that names a C or assembly language entity should have the name of that entity. For example, a C function called calculate generates a symbol called calculate (not _calculate). See http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf Linux system returns the correct __USER_LABEL_PREFIX__: $ clang-3.8 -E -dM -ffreestanding -target arm-linux-eabi - < /dev/null | grep __USER_LABEL_PREFIX__ #define __USER_LABEL_PREFIX__ $ clang-3.8 -E -dM -ffreestanding -target arm-linux-gnueabihf - < /dev/null | grep __USER_LABEL_PREFIX__ #define __USER_LABEL_PREFIX__ while the 'none' system returns '_': $ clang-3.8 -E -dM -ffreestanding -target arm-none-eabi - < /dev/null | grep __USER_LABEL_PREFIX__ #define __USER_LABEL_PREFIX__ _ $ clang-3.8 -E -dM -ffreestanding -target arm-none-gnueabihf - < /dev/null | grep __USER_LABEL_PREFIX__ #define __USER_LABEL_PREFIX__ _ -- 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 25509] New: [LIR] Misses simple memset case
https://llvm.org/bugs/show_bug.cgi?id=25509
Bug ID: 25509
Summary: [LIR] Misses simple memset case
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
LLVM is unable to generate a memset from the below test:
void test(int *arr) {
for (int i = 0; i < 1024; ++i) {
arr[i] = 0;
arr[i+1024] = 0;
}
}
As of r252817 clang produces:
test: // @test
// BB#0:// %entry
mov x8, xzr
moviv0.2d, #
.LBB0_1:// %vector.body
// =>This Inner Loop Header: Depth=1
add x9, x0, x8
add x8, x8, #16 // =16
str q0, [x9]
str q0, [x9, #4096]
cmp x8, #1, lsl #12 // =4096
b.ne.LBB0_1
// BB#2:// %for.cond.cleanup
ret
GCC is able to generate 2 memsets (one per arr access). If I'm not mistaken
this can be transformed into a single memset (i.e., memset(arr, 0, 2048)).
--
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 25028] [mips64] Incorrect dwarf info
https://llvm.org/bugs/show_bug.cgi?id=25028 Vasileios Kalintiris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Vasileios Kalintiris --- Fixed in r252884. Please, test and re-open the bug if it's still causing problems. -- 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 25440] assertion in GVN
https://llvm.org/bugs/show_bug.cgi?id=25440 Weiming Zhao changed: 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 25505] [Polly] Loop invariant code motion, structures and non-power-of-two types cause miscompile
https://llvm.org/bugs/show_bug.cgi?id=25505 Tobias Grosser changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Grosser --- This issue has been resolved in r252942. -- 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 25510] New: __builtin_cpu_supports("sse3") compiles, but fails when linking.
https://llvm.org/bugs/show_bug.cgi?id=25510
Bug ID: 25510
Summary: __builtin_cpu_supports("sse3") compiles, but fails
when linking.
Product: lld
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: p...@shifteleven.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I am compiling on OSX 10.11 with clang-3.7 from macports. Here's some sample
code to demonstrate the problem:
#include
#include
int main() {
#if(__has_builtin(__builtin_cpu_supports)) && defined(__x86_64__)
printf("__builtin_cpu_supports: %d\n", __builtin_cpu_supports("sse3"));
#else
printf("__builtin_cpu_cupports not available\n");
#endif
return EXIT_SUCCESS;
}
If I compile with clang-3.7 or clang-3.8 (both which claim to have the builtin
cpu supports), everything works. However, during linking, I get the following:
Undefined symbols for architecture x86_64:
"___cpu_model", referenced from:
_dt_init in darktable.c.o
ld: symbol(s) not found for architecture x86_64
With earlier versions of clang, I see the else clause.
I have also seen this in the wild where this problem exists for FreeBSD as
well.
https://github.com/darktable-org/darktable/commit/081bc5823870918160fdd93d0157d56263add7d5.
--
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 25511] New: Clang3.6 compile error: definition of builtin function, while gcc4.8 pass
https://llvm.org/bugs/show_bug.cgi?id=25511
Bug ID: 25511
Summary: Clang3.6 compile error: definition of builtin
function, while gcc4.8 pass
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: derr...@ca.ibm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
It seems Clang doesn't like the definition of the builtin, as followed.
File 1.cpp:
int __builtin_eh_return_data_regno(int i)
{
return 0;
}
int main()
{
return 0;
}
gcc compile, success:
$g++ -c 1.cpp -o test.o
clang compile, Failure:
clang++ -c 1.cpp -fno-builtin -o test.o
1.cpp:1:5: error: definition of builtin function
'__builtin_eh_return_data_regno'
int __builtin_eh_return_data_regno(int i)
^
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 25512] New: Optimization corrupts debug info
https://llvm.org/bugs/show_bug.cgi?id=25512
Bug ID: 25512
Summary: Optimization corrupts debug info
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: daniel...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Source: a.cc
1 int *A;
2 void bar(int i);
3
4 void foo(int i) {
5 if (i > 100) {
6 bar(A[20]);
7 } else {
8 bar(A[15]);
9 }
10 }
#clang -g a.cc -c -O2
#objdump -d a.o
<_Z3fooi>:
0:48 8b 05 00 00 00 00 mov0x0(%rip),%rax# 7
<_Z3fooi+0x7>
7:83 ff 65 cmp$0x65,%edi
a:7c 08jl 14 <_Z3fooi+0x14>
c:8b 78 50 mov0x50(%rax),%edi
f:e9 00 00 00 00 jmpq 14 <_Z3fooi+0x14>
14:8b 78 3c mov0x3c(%rax),%edi
17:e9 00 00 00 00 jmpq 1c <_Z3fooi+0x1c>
#addr2line -e a.o -i 0x0
/ssd/llvm_commit/build.afdo/a.cc:6
The problem is, the first mov instruction is attributed to the source that's in
the taken branch. From debugger's point of few, when you enter this function,
gdb will start with line #6, even though the logic does not get into #6 at all.
This makes things worse when using debug info to represent profile. In this
case, #6 will have the same count as the branch entry. As a result, even if the
branch is never taken, the profile will still consider the branch as at least
50% taken.
There are many optimizations that would have this effect. Usually, compiler
developers does not care too much about debugging of optimized code. But if we
can address most issues like this where optimizations would skew the debug
info, not only can we have better debugging experience of optimized code, we
also get better performance when using sampling based profile to guide
optimizations.
--
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 25482] Debug info not maintained in AutoFDO
https://llvm.org/bugs/show_bug.cgi?id=25482 Dehao Chen changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Dehao Chen --- The inline stack is still not maintained correctly in this bug. Here is how to reproduce: #bin/clang++ -c -fprofile-sample-use=c.txt -O2 -save-temps -v c.cc #bin/opt -sample-profile -sample-profile-file=c.txt c.bc -S|bin/opt -analyze -branch-prob Printing analysis 'Branch Probability Analysis' for function '_Z3foov': Branch Probabilities edge entry -> if.then.i probability is 0x5000 / 0x8000 = 62.50% edge entry -> if.else.i probability is 0x3000 / 0x8000 = 37.50% edge if.then.i -> _ZL3barv.exit probability is 0x8000 / 0x8000 = 100.00% [HOT edge] edge if.else.i -> _ZL3barv.exit probability is 0x8000 / 0x8000 = 100.00% [HOT edge] Printing analysis 'Branch Probability Analysis' for function '_ZL3barv': Branch Probabilities edge entry -> if.then probability is 0x5000 / 0x8000 = 62.50% edge entry -> if.else probability is 0x3000 / 0x8000 = 37.50% edge if.then -> if.end probability is 0x8000 / 0x8000 = 100.00% [HOT edge] edge if.else -> if.end probability is 0x8000 / 0x8000 = 100.00% [HOT edge] #bin/clang++ -c -fprofile-sample-use=c.txt -O2 -save-temps -v c.cc -g #bin/opt -sample-profile -sample-profile-file=c.txt c.bc -S|bin/opt -analyze -branch-prob Printing analysis 'Branch Probability Analysis' for function '_Z3foov': Branch Probabilities edge entry -> if.then.i probability is 0x / 0x8000 = 0.00% edge entry -> if.else.i probability is 0x8000 / 0x8000 = 100.00% [HOT edge] edge if.then.i -> _ZL3barv.exit probability is 0x8000 / 0x8000 = 100.00% [HOT edge] edge if.else.i -> _ZL3barv.exit probability is 0x8000 / 0x8000 = 100.00% [HOT edge] Printing analysis 'Branch Probability Analysis' for function '_ZL3barv': Branch Probabilities edge entry -> if.then probability is 0x5000 / 0x8000 = 62.50% edge entry -> if.else probability is 0x3000 / 0x8000 = 37.50% edge if.then -> if.end probability is 0x8000 / 0x8000 = 100.00% [HOT edge] edge if.else -> if.end probability is 0x8000 / 0x8000 = 100.00% [HOT edge] With and without "-g", branch-probability gives different branch probability estimation for _Z3foov. -- 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 25513] New: is_constructible should be false
https://llvm.org/bugs/show_bug.cgi?id=25513
Bug ID: 25513
Summary: is_constructible should be false
Product: clang
Version: 3.7
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sfi...@hotmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15283
--> https://llvm.org/bugs/attachment.cgi?id=15283&action=edit
self contained repro
Function types shouldn't be considered constructible (unless I am completely
confused).
C:\Temp>type meow.cpp
template struct is_constructible {
static constexpr bool value = __is_constructible(T, Args...);
};
template struct is_nothrow_constructible {
static constexpr bool value = __is_nothrow_constructible(T, Args...);
};
template struct is_trivially_constructible {
static constexpr bool value = __is_trivially_constructible(T, Args...);
};
static_assert(! is_constructible::value, "BOOM");
static_assert(! is_nothrow_constructible::value, "BOOM");
static_assert(!is_trivially_constructible::value, "BOOM");
/***
N4527 20.10.4.3 [meta.unary.prop]/7:
Given the following function declaration:
template
add_rvalue_reference_t create() noexcept;
the predicate condition for a template specialization is_constructible
shall be satisfied if and only if the following variable definition would be
well-formed for some invented variable t:
T t(create()...);
[ Note: These tokens are never interpreted as a function declaration. -end note
]
Access checking is performed as if in a context unrelated to T and any of the
Args.
Only the validity of the immediate context of the variable initialization is
considered.
[ Note: The evaluation of the initialization can result in side effects such as
the
instantiation of class template specializations and function template
specializations,
the generation of implicitly-defined functions, and so on. Such side effects
are not
in the "immediate context" and can result in the program being ill-formed. -end
note ]
***/
C1XX accepts:
C:\Temp>cl /EHsc /nologo /W4 /c meow.cpp
meow.cpp
But Clang/C2 rejects:
C:\Temp>clang-cl /EHsc /nologo /W4 /c meow.cpp
meow.cpp(13,1) : error: static_assert failed "BOOM"
static_assert(! is_constructible::value, "BOOM");
^ ~
meow.cpp(14,1) : error: static_assert failed "BOOM"
static_assert(! is_nothrow_constructible::value, "BOOM");
^ ~
meow.cpp(15,1) : error: static_assert failed "BOOM"
static_assert(!is_trivially_constructible::value, "BOOM");
^ ~
3 errors generated.
This is NOT specific to Clang/C2 - http://melpon.org/wandbox/ also rejects. The
same thing happens if libc++ is used instead of the compiler
hooks used above.
--
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 25514] New: [WinEH] x64 UnwindHelp offset is wrong for realigned stack frames
https://llvm.org/bugs/show_bug.cgi?id=25514
Bug ID: 25514
Summary: [WinEH] x64 UnwindHelp offset is wrong for realigned
stack frames
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: david.majne...@gmail.com, jctremou...@gmail.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
#include
struct HasDtor {
~HasDtor() { puts("~HasDtor"); }
};
void throwit() { throw 2; }
void *p;
void realigned() {
__declspec(align(64)) HasDtor o;
p = &o;
throwit();
}
int main() {
try {
realigned();
} catch (...) {
puts("caught");
}
}
We generate this cppxdata:
$cppxdata$main:
.long 429065506
.long 2
.long ($stateUnwindMap$main)@IMGREL
.long 1
.long ($tryMap$main)@IMGREL
.long 3
.long ($ip2state$main)@IMGREL
.long 40
.long 0
.long 1
It says that UnwindHelp is at offset 40 of RSP-after-prologue. However, we
allocate UnwindHelp using a regular stack object (not fixed), so it is actually
in the local variable area, which is realigned. Our initialization of this slot
with -2 shows that:
subq$104, %rsp
...
.seh_endprologue
andq$-64, %rsp
movq%rsp, %rbx
movq%rbp, 48(%rbx)
movq$-2, 56(%rbx)
RBX + 56 is not the same memory as RSP-after-prologue + 40.
Found in this test:
https://github.com/Microsoft/compiler-tests/blob/master/eh/ehframes.cpp
--
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 11740] can't use clang -g to assemble .s file with .file directive
https://llvm.org/bugs/show_bug.cgi?id=11740
yunlian changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||yunl...@google.com
Resolution|FIXED |---
--- Comment #4 from yunlian ---
cat a.c
void foo() {}
clang -g a.c -S -o a.s
clang -g -c -o a.o a.s
a.s:8:2: error: input can't have .file dwarf directives when -g is used to
generate dwarf debug info for assembly code
.file 1 "a.c"
^
a.s:8:8: error: file number already allocated
.file 1 "a.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
[llvm-bugs] [Bug 23761] Installing scan-build and scan-view
https://llvm.org/bugs/show_bug.cgi?id=23761 Eugene Zelenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eugene Zelenko --- Implemented in r252474 and subsequent revisions. -- 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 25513] is_constructible should be false
https://llvm.org/bugs/show_bug.cgi?id=25513 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | -- 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 25515] New: Amil Sing
https://llvm.org/bugs/show_bug.cgi?id=25515 Bug ID: 25515 Summary: Amil Sing Product: libc++ Version: unspecified Hardware: HP OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: kaaalid555...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified -- 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 25516] New: Mida
https://llvm.org/bugs/show_bug.cgi?id=25516 Bug ID: 25516 Summary: Mida Product: Documentation Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: kaaalid555...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- 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
