[llvm-bugs] [Bug 38820] New: Decl.cpp:2332: bool clang::VarDecl::checkInitIsICE() const: Assertion `!Init->isValueDependent()' failed
https://bugs.llvm.org/show_bug.cgi?id=38820 Bug ID: 38820 Summary: Decl.cpp:2332: bool clang::VarDecl::checkInitIsICE() const: Assertion `!Init->isValueDependent()' failed Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: balarishi.bhog...@amd.com CC: llvm-bugs@lists.llvm.org Created attachment 20831 --> https://bugs.llvm.org/attachment.cgi?id=20831&action=edit Reduced testcase file to reproduce the issue Faced the below assertion failure: /home/amd/JENKINS/workspace/Staging_Build_Tracker/llvm/tools/clang/lib/AST/Decl.cpp:2332: bool clang::VarDecl::checkInitIsICE() const: Assertion `!Init->isValueDependent()' failed. Steps to reproduce the issue with the reduced testcase: - Download the attached file - Compile the cpp file using the below command clang++ CE_assertion_err.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 38796] Merge r340959 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=38796 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r341351. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38796, which changed state. Bug 38796 Summary: Merge r340959 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=38796 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 38707] SROA can create badly-aligned/misaligned slices
https://bugs.llvm.org/show_bug.cgi?id=38707 Hans Wennborg 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38707, which changed state. Bug 38707 Summary: SROA can create badly-aligned/misaligned slices https://bugs.llvm.org/show_bug.cgi?id=38707 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 38821] New: Invalid counters with a switch statement
https://bugs.llvm.org/show_bug.cgi?id=38821
Bug ID: 38821
Summary: Invalid counters with a switch statement
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: profile
Assignee: cdeni...@mozilla.com
Reporter: cdeni...@mozilla.com
CC: llvm-bugs@lists.llvm.org, mcastelluc...@mozilla.com
Here is the C code:
int main(void)
{
int i = 22;
switch (i) {
case 7:
break;
case 22:
i = 7;
break;
case 42:
break;
}
return 0;
}
The .c.gcov is:
-:0:Source:sl.c
-:0:Graph:sl.gcno
-:0:Data:sl.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int main(void)
-:2:{
2:3: int i = 22;
-:4:
2:5: switch (i) {
-:6:case 7:
#:7: break;
-:8:
-:9:case 22:
1: 10: i = 7;
1: 11: break;
-: 12:
-: 13:case 42:
#: 14: break;
-: 15: }
-: 16:
1: 17: return 0;
-: 18:}
Notice the 2 on lines 3 and 5.
And a gcda dump gives:
= main (0) @ sl.c:1
Block : 0 Counter : 1
Destination Edges : 1 (1),
Block : 1 Counter : 2
Source Edges : 0 (1),
Destination Edges : 2 (0), 3 (1), 4 (0), 5 (1),
Lines : 3,5,
Block : 2 Counter : 0
Source Edges : 1 (0),
Destination Edges : 5 (0),
Lines : 7,
Block : 3 Counter : 1
Source Edges : 1 (1),
Destination Edges : 5 (1),
Lines : 10,11,
Block : 4 Counter : 0
Source Edges : 1 (0),
Destination Edges : 5 (0),
Lines : 14,
Block : 5 Counter : 1
Source Edges : 1 (1), 2 (0), 3 (1), 4 (0),
Destination Edges : 6 (1),
Lines : 17,
Block : 6 Counter : 1
Source Edges : 5 (1),
File 'sl.c'
Lines executed:71.43% of 7
sl.c:creating 'sl.c.gcov'
The block 1 has a branch to block 5, but this branch is not taken so the
counter for 1->5 must be 0.
--
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 38822] New: debug info is missing information about a structure.
https://bugs.llvm.org/show_bug.cgi?id=38822 Bug ID: 38822 Summary: debug info is missing information about a structure. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: dimi...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 20834 --> https://bugs.llvm.org/attachment.cgi?id=20834&action=edit lib.cc This is a reproducer: clang++ -fPIC -g -shared -o lib.so lib.cc readelf -wai lib.so <1><54>: Abbrev Number: 6 (DW_TAG_structure_type) <55> DW_AT_name: (indirect string, offset: 0x11a): Foo <59> DW_AT_declaration : 1 Where if the same file compiled using g++ it provides full information about structure_type: g++ -fPIC -g -shared -o lib.so lib.cc readelf -wai lib.so ... <1><2d>: Abbrev Number: 2 (DW_TAG_structure_type) <2e> DW_AT_name: Foo <32> DW_AT_byte_size : 4 <33> DW_AT_decl_file : 2 <34> DW_AT_decl_line : 1 <35> DW_AT_sibling : <0x46> <2><39>: Abbrev Number: 3 (DW_TAG_member) <3a> DW_AT_name: (indirect string, offset: 0x41): value <3e> DW_AT_decl_file : 2 <3f> DW_AT_decl_line : 2 <40> DW_AT_type: <0x46> <44> DW_AT_data_member_location: 0 ... It would be nice to have full debug info of a referenced structure even when some fields of this structure are not used. -- 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 38823] New: 'Undefined reference's with explicit instantiation of template class with virtual members
https://bugs.llvm.org/show_bug.cgi?id=38823
Bug ID: 38823
Summary: 'Undefined reference's with explicit instantiation of
template class with virtual members
Product: OpenMP
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: hah...@hahnjo.de
CC: llvm-bugs@lists.llvm.org
Created attachment 20836
--> https://bugs.llvm.org/attachment.cgi?id=20836&action=edit
source code detailing the problem
Consider something like the following:
$ cat virtual.cpp
template
struct Base {
virtual ~Base() {}
virtual void test() const {}
void offload() {
#pragma omp target
{}
}
};
#ifndef IMPLICIT
template class Base;
#endif
int main(int argc, char *argv[]) {
#ifdef IMPLICIT
Base b;
#endif
return 0;
}
$ clang++ -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda virtual.cpp
[...]
Undefined reference to '_ZdlPv'
Undefined reference to '_ZTVN10__cxxabiv117__class_type_infoE'
[...]
$ c++filt _ZdlPv
operator delete(void*)
$ c++filt _ZTVN10__cxxabiv117__class_type_infoE
vtable for __cxxabiv1::__class_type_info
Additional notes:
1) When instantiating the template implicitly (-DIMPLICIT), the error goes
away.
2) The vtable for __class_type_info goes away when compiling with -fno-rtti.
3) Commenting out the virtual destructor removes the reference to "operator
delete". I think the destructor is emitted because it is listed in the classes
vtable?
--
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 38824] New: debug_info missing parameters for naked functions
https://bugs.llvm.org/show_bug.cgi?id=38824
Bug ID: 38824
Summary: debug_info missing parameters for naked functions
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dimi...@google.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20837
--> https://bugs.llvm.org/attachment.cgi?id=20837&action=edit
source file
Source file:
extern "C" void naked_function(int value, char* name);
extern "C" void regular_function(int value, char* name);
void __attribute__((naked, noinline)) naked_function(int value, char* name) {
}
void regular_function(int value, char* name) {
}
Command line:
clang++ -g --shared -fPIC -o libtest.so src.cc
Result:
$ readelf -wi libtest.so
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x81 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer: (indirect string, offset: 0x0): clang version
8.0.0 (https://git.llvm.org/git/clang.git/
1bc73590ad1335313e8f262393547b8af67c9167) (https://git.llvm.org/git/llvm.git/
24a8df2c420ee959f27acae6bac2969cdd0a5388)
<10> DW_AT_language: 4(C++)
<12> DW_AT_name: (indirect string, offset: 0xb1): src.cc
<16> DW_AT_stmt_list : 0x0
<1a> DW_AT_comp_dir: (indirect string, offset: 0xb8):
/ssd/llvm/test/naked_debug_info
<1e> DW_AT_low_pc : 0x610
<26> DW_AT_high_pc : 0x1d
<1><2a>: Abbrev Number: 2 (DW_TAG_subprogram)
<2b> DW_AT_low_pc : 0x610
<33> DW_AT_high_pc : 0x7
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_name: (indirect string, offset: 0xd8): naked_function
<3d> DW_AT_decl_file : 1
<3e> DW_AT_decl_line : 4
<3f> DW_AT_external: 1
<1><3f>: Abbrev Number: 3 (DW_TAG_subprogram)
<40> DW_AT_low_pc : 0x620
<48> DW_AT_high_pc : 0xd
<4c> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<4e> DW_AT_name: (indirect string, offset: 0xe7):
regular_function
<52> DW_AT_decl_file : 1
<53> DW_AT_decl_line : 7
<54> DW_AT_external: 1
<2><54>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<55> DW_AT_location: 2 byte block: 91 7c (DW_OP_fbreg: -4)
<58> DW_AT_name: (indirect string, offset: 0xf8): value
<5c> DW_AT_decl_file : 1
<5d> DW_AT_decl_line : 7
<5e> DW_AT_type: <0x71>
<2><62>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<63> DW_AT_location: 2 byte block: 91 70 (DW_OP_fbreg: -16)
<66> DW_AT_name: (indirect string, offset: 0x102): name
<6a> DW_AT_decl_file : 1
<6b> DW_AT_decl_line : 7
<6c> DW_AT_type: <0x78>
<2><70>: Abbrev Number: 0
<1><71>: Abbrev Number: 5 (DW_TAG_base_type)
<72> DW_AT_name: (indirect string, offset: 0xfe): int
<76> DW_AT_encoding: 5(signed)
<77> DW_AT_byte_size : 4
<1><78>: Abbrev Number: 6 (DW_TAG_pointer_type)
<79> DW_AT_type: <0x7d>
<1><7d>: Abbrev Number: 5 (DW_TAG_base_type)
<7e> DW_AT_name: (indirect string, offset: 0x107): char
<82> DW_AT_encoding: 6(signed char)
<83> DW_AT_byte_size : 1
<1><84>: Abbrev Number: 0
Note that while parameters for not naked function are preserved naked function
parameters are lost.
--
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 38825] New: Error when mapping a structure and a contained array section
https://bugs.llvm.org/show_bug.cgi?id=38825
Bug ID: 38825
Summary: Error when mapping a structure and a contained array
section
Product: OpenMP
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: hah...@hahnjo.de
CC: llvm-bugs@lists.llvm.org
Created attachment 20838
--> https://bugs.llvm.org/attachment.cgi?id=20838&action=edit
Example code
I may be wrong here with my interpretation of the standard. If so, feel free to
close as INVALID.
$ cat structure-pointer.c
#include
typedef struct {
int *ptr;
int val;
} StructWithPtr;
int main(int argc, char *argv[]) {
StructWithPtr s;
s.ptr = malloc(sizeof(int));
s.ptr[0] = 1;
s.val = 2;
#pragma omp target map(s, s.ptr[0:1])
{
s.val++;
s.ptr[0]++;
}
free(s.ptr);
return 0;
}
$ clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda structure-pointer.c
structure-pointer.c:14:27: error: variable already marked as mapped in current
construct
#pragma omp target map(s, s.ptr[0:1])
^~
structure-pointer.c:14:24: note: used here
#pragma omp target map(s, s.ptr[0:1])
1 error generated.
I can't find a restriction in standards newer than OpenMP 4.5 but I remember
some discussion about patterns like this (StructWithPtr my have many more
members that would clutter the map clause if listed explicitly).
In the light of p309:1-17 I think this should be allowed.
--
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 34251] ms-pdb: missing pdb for lib shouldn't be fatal
https://bugs.llvm.org/show_bug.cgi?id=34251 Alexandre Ganea changed: What|Removed |Added CC||alexandre.ga...@ubisoft.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Ganea --- Fixed by r323893. -- 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 36196] lld produces malformed PDB
https://bugs.llvm.org/show_bug.cgi?id=36196 Alexandre Ganea changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||alexandre.ga...@ubisoft.com -- 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 38704] libomptarget/src/omptarget.cpp:440: bad erase ?
https://bugs.llvm.org/show_bug.cgi?id=38704 Jonas Hahnfeld changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r341371 --- Comment #6 from Jonas Hahnfeld --- Landed in r341371. -- 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 38826] New: [7, trunk, regression][x86 backend] .cfi_offset doesn't allow %eip in 32bit mode
https://bugs.llvm.org/show_bug.cgi?id=38826 Bug ID: 38826 Summary: [7, trunk, regression][x86 backend] .cfi_offset doesn't allow %eip in 32bit mode Product: new-bugs Version: 7.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: iains-l...@btconnect.com CC: llvm-bugs@lists.llvm.org Created attachment 20839 --> https://bugs.llvm.org/attachment.cgi?id=20839&action=edit possible patch For 7.0.0rc2 and trunk, the following code: .text .align 4 .globl foo foo: .cfi_startproc movl (%edx), %ecx movl 4(%edx), %ebx movl 8(%edx), %esi movl 12(%edx), %edi movl 16(%edx), %ebp .cfi_def_cfa %edx, 0 .cfi_offset %eip, 24 .cfi_register %esp, %ecx movl %ecx, %esp jmp *24(%edx) .cfi_endproc === produces $ /bin/llvm-mc -triple i386-unknown-unkown -filetype obj foo.s -o t.o :259:18: error: register %eip is only available in 64-bit mode .cfi_offset %eip, 24 this seems to be down to : r336217 "[X86][AsmParser] Don't consider %eip as a valid register outside of 32-bit mode." ... except that we are in 32b mode ... The issue is that we want to exclude eip from use in base+index modes, but not from all uses? -- 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 38827] New: Static Analyzer Segfaults in cplusplus.Innterpointer
https://bugs.llvm.org/show_bug.cgi?id=38827 Bug ID: 38827 Summary: Static Analyzer Segfaults in cplusplus.Innterpointer Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: developm...@jonas-toth.eu CC: llvm-bugs@lists.llvm.org Created attachment 20840 --> https://bugs.llvm.org/attachment.cgi?id=20840&action=edit Reproducer to trigger the bug Hello, this bug report comes from the cfe-dev mailing list (http://clang-developers.42468.n3.nabble.com/Clang-tidy-crashes-when-string-reference-used-as-parameter-td4061941.html) The analyzer is run from clang-tidy(almost trunk, clang as well, NOT release branch): clang-tidy -checks=-*,clang-analyzer-cplusplus.InnerPointer clang-tidy-bug.cpp -- I could not reproduce with clang-tidy-6, is this analysis new? Maybe this bug is a potential blocker for the release! -- 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 38828] New: Incorrect assembly emitted for cmpxchg IR instruction on thumbv7m-none-eabi target
https://bugs.llvm.org/show_bug.cgi?id=38828 Bug ID: 38828 Summary: Incorrect assembly emitted for cmpxchg IR instruction on thumbv7m-none-eabi target Product: new-bugs Version: trunk Hardware: Other OS: other Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mvirkku...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 20841 --> https://bugs.llvm.org/attachment.cgi?id=20841&action=edit C program that reproduces the problem When compiled with: clang -c -target thumbv7m-none-eabi -O1 compare_exchange.c The attached C program produces invalid assembly code that attempts to load a value from outside the function's stack frame in the first "ldrex" instruction of the compare exchange operation. The rest of the stack access generated by the cmpxchg seem to be correct. More weird results can be obtained by adding/removing "int"s before the atomic one. I've also attached the generated assembly and IR code from my machine. The problem seems to be on the assembly generation level and not in clang itself (I ran into this while using Rust). The example program uses intrinsics instead of standard C to make sure it's not a header issue, but the same problem happens with stdatomic.h. Compiling with "-target thumbv7-none-eabi" instead seems to produce correct code, as well as compiling with -O0. LLVM version: Tip of trunk from SVN, as well as 6.0.0-1ubuntu2 (my machine, from the official Ubuntu repositories) Godbolt link for quick verification: https://godbolt.org/z/Ozr2xa -- 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 38822] debug info is missing information about a structure.
https://bugs.llvm.org/show_bug.cgi?id=38822 Reid Kleckner changed: What|Removed |Added CC||r...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Emitting a declaration for struct types when the type is not required to be complete (i.e. none of the fields are referenced) is an important debug info size optimization for many of our users. If the struct is used anywhere in your program, the complete struct definition should be provided by the TU that uses it. If only part of your program is compiled with debug info, you can use -fstandalone-debug (or -fno-limit-debug-info, another alias) to get clang to emit everything. It's possible that we don't have the right default, but for many users, emitting more debug info by default would make binaries unusably large. If, at some point in the future, we can enable DWARF type units or other type info deduplication technology by default, we might be able to emit all types by default, and put this size optimization behind a flag for users with particularly large binaries. I'm not sure what the best resolution status is for this, but I will use "fixed" to mean that a flag exists for the behavior that you want. -- 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 38829] New: Quadratic behavior in DSE and memcpyopt from use of callCapturesBefore without an OrderedBasicBlock
https://bugs.llvm.org/show_bug.cgi?id=38829 Bug ID: 38829 Summary: Quadratic behavior in DSE and memcpyopt from use of callCapturesBefore without an OrderedBasicBlock Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: chandl...@gmail.com, dber...@dberlin.org, george.burgess...@gmail.com, llvm-bugs@lists.llvm.org My local build of clang was slow, so I profiled it, and this is what I found. I compiled on Windows with optimizations and debug info. I think enabling debug info makes basic blocks longer, and that's the main reason it matters. Compiling clang's SemaChecking.cpp file took ~121s total, and of it, 21s is spent in DSE and 21s in memcpyopt. The majority of the time in both of these passes was in callCapturesBefore. The next most expensive pass is induction variable simplification at 14s, but its time is spent in SCEV, not AA. Most of the time in DSE and memcpyopt is spent in callCapturesBefore, which is linear in the size of the basic block in the worst case. Most of the samples occur in OrderedBlock::comesBefore, which is the inner loop that iterates the linked list of instructions in a BB and numbers them to compute intra-BB dominance. If we could, for example, maintain accurate position numbers for instructions in the basic block, this would not be necessary, but it would require a fancy algorithm to maintain amortized O(1) insertion and removal of instructions mid-block. Fixing this without that fancy algorithm seems like a bit of a pain, since we can't blindly create an OrderedBasicBlock in our transforms that use callCapturesBefore. These passes currently add and remove instructions as they go, mutating the block. We'd probably end up seeing ABA bugs where freed instruction addresses appear in the OrderedBasicBlock DenseMap that maps from Instruction* to position. Every place where we update the domtree today, we'd have to update the appropriate basic block. These passes already both use MemoryDependenceResults and call MD->removeInstruction. In theory we could move the instruction numbering into MemoryDependenceResults, and have it be responsible for maintaining the numbers, but its starting to feel like adding fancy algorithms to ilist / iplist would be more maintainable. -- 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 38830] New: Memory corruption with CodeGenOnly in ThinLTOCodeGenerator
https://bugs.llvm.org/show_bug.cgi?id=38830
Bug ID: 38830
Summary: Memory corruption with CodeGenOnly in
ThinLTOCodeGenerator
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: alex.b...@gmail.com
CC: llvm-bugs@lists.llvm.org
When running with ThinLTO & CodeGenOnly, TMBuilder.TheTriple is initialized
from multiple threads in a non-thread-safe way.
Pseudocode:
if (CodeGenOnly) {
// Perform only parallel codegen and return.
ThreadPool Pool;
int count = 0;
for (auto &ModuleBuffer : Modules) {
Pool.async([&](int count) {
...
/// Now call OutputBuffer = codegen(*TheModule);
/// Which turns into initTMBuilder(moduleTMBuilder,
Triple(TheModule.getTargetTriple()));
/// Which turns into
TMBuilder.TheTriple = std::move(TheTriple); // std::string = "."
/// So, basically std::string assignment to same string on multiple
threads = memory corruption
}
return;
}
--
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 38831] New: AArch64 assembly gives error in one case but not in other equivalent case.
https://bugs.llvm.org/show_bug.cgi?id=38831 Bug ID: 38831 Summary: AArch64 assembly gives error in one case but not in other equivalent case. Product: libraries Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: jakehehrl...@google.com CC: llvm-bugs@lists.llvm.org The following instruction assembles successfully ``` adr x9, IMAGE_LOAD_START + 987136 ``` but somehow the following does not ``` adr x9, (0x000f1000 - 0x + IMAGE_LOAD_START) ``` Regardless of how IMAGE_LOAD_START is defined these should resolved to the same value. I'll try and post a more complete and simpler reproducer later rather than one pulled almost directly from real code however simple it may 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 38817] -fansi-escape-codes should set Windows console mode
https://bugs.llvm.org/show_bug.cgi?id=38817 David Bolvansky 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38832] New: [llvm-mca] Add binary support to llvm-mca.
https://bugs.llvm.org/show_bug.cgi?id=38832 Bug ID: 38832 Summary: [llvm-mca] Add binary support to llvm-mca. Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: matthew.da...@sony.com CC: llvm-bugs@lists.llvm.org Currently, llvm-mca operates on asm source. The goal of this bug/feature is to give llvm-mca the ability to operate on object files and not just asm source. This change will require llvm-mca to enable/initialize the target disassemblers and locate user-annotated code regions. Each code region should be executed in a separate simulated pipeline within llvm-mca, similar to how llvm-mca currently executes multiple code regions that have been annotated in the user's asm source. To locate user defined code regions in an object file, llvm will need to store the start/end .text offsets, that represent the user's annotations, into a MCSection of the user's object file. For an ELF file, this can be a section called ".mca_code_segments", where the content of this region is a set of pairs: <.text offset begin, .text offset end>. llvm-mca will locate these code regions, and perform analysis on each region within a simulated pipeline. This change will probably require a pair of intrinsics, to represent the user's annotations, which will eventually be lowered into a representation that will be used to make up the contents of the llvm-mca specific MCSection. An example looks something like the following: .text .Lmca_segment1_start: ... # Code to be analyzed by mca .Lmca_segment1_end: ... # More code, not analyzed by mca .mca_code_segments: .Lmca_segment1_start, .Lmca_segment1_end -- 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 38833] New: __builtin_isinf[_sign] yield incorrect results on X86 when using x87 math
https://bugs.llvm.org/show_bug.cgi?id=38833
Bug ID: 38833
Summary: __builtin_isinf[_sign] yield incorrect results on X86
when using x87 math
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: and...@anarazel.de
CC: llvm-bugs@lists.llvm.org
Hi,
(thanks to Andrew Gierth for the test program and help in narrowing this down)
$ cat ~/tmp/flttst.c
#include
#include
int main(int argc, char **argv)
{
double d1 = (argc ? 1e180 : 0);
double d2 = (argv ? 1e200 : 0);
int r2 = __builtin_isinf_sign(d1 * d2);
int r1 = isinf(d1 * d2);
printf("r1 = %d, r2 = %d\n", r1, r2);
return 0;
}
$ clang-8 -std=c99 -march=i386 -O2 -m32 ~/tmp/flttst.c -o ~/tmp/flttst &&
~/tmp/flttst
r1 = 1, r2 = 0
$ clang-8 -std=c99 -march=pentium4 -O2 -m32 ~/tmp/flttst.c -o ~/tmp/flttst &&
~/tmp/flttst
r1 = 1, r2 = 1
The issue appears to be that the use of x87 math, with its 80bit registers,
avoids the overflow. This appears to be a C99 violation - note that gcc
enables its -fexcess-precision=standard automatically in C99 mode.
We only noticed this because clang on freebsd (and other bsds) defaults to
targetting 486, whereas linux targets pentium4 (which has non x87 math). That
caused postgres' tests to fail on 32bit x86 freebsd, after starting to use the
intrinsic, whereas linux was fine.
Regards,
Andres Freund
--
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 38669] Verbose mode unicode archive name printing is incorrect
https://bugs.llvm.org/show_bug.cgi?id=38669 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Reid Kleckner --- Thanks, fixed in r341433 with WriteConsoleW. -- 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 36267] Less than ideal handling of variable names in Cyrillic alphabet
https://bugs.llvm.org/show_bug.cgi?id=36267 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #45 from Reid Kleckner --- Fixed in r341433 by using WriteConsoleW. Now I get this in my console: $ clang -c t.cpp t.cpp:3:17: error: static_assert expression is not an integral constant expression static_assert(переменная, ""); ^~ t.cpp:3:17: note: read of non-const variable 'переменная' is not allowed in a constant expression t.cpp:2:7: note: declared here int переменная = 1; ^ 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 38834] New: -gdb-set args is not implemented
https://bugs.llvm.org/show_bug.cgi?id=38834 Bug ID: 38834 Summary: -gdb-set args is not implemented Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: malape...@gmail.com CC: llvm-bugs@lists.llvm.org Using lldb 8.0.0 (r341271). The mi "-gdb-set args" is not implemented, it has no effect. But -exec-arguments is implemented and should be the same I think. -- 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 38221] error: unknown instruction for inline asm "cvt.s.pl %0, %4\n\t"
https://bugs.llvm.org/show_bug.cgi?id=38221 Leslie Zhai 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 38835] New: AnnotateAttr leaks its annotations
https://bugs.llvm.org/show_bug.cgi?id=38835
Bug ID: 38835
Summary: AnnotateAttr leaks its annotations
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mh+l...@glandium.org
CC: llvm-bugs@lists.llvm.org
The full generated code for AnnotateAttr is:
class AnnotateAttr : public InheritableParamAttr {
unsigned annotationLength;
char *annotation;
public:
static AnnotateAttr *CreateImplicit(ASTContext &Ctx, llvm::StringRef
Annotation, SourceRange Loc = SourceRange()) {
auto *A = new (Ctx) AnnotateAttr(Loc, Ctx, Annotation, 0);
A->setImplicit(true);
return A;
}
AnnotateAttr(SourceRange R, ASTContext &Ctx
, llvm::StringRef Annotation
, unsigned SI
)
: InheritableParamAttr(attr::Annotate, R, SI, false, false)
, annotationLength(Annotation.size()),annotation(new (Ctx, 1)
char[annotationLength])
{
if (!Annotation.empty())
std::memcpy(annotation, Annotation.data(), annotationLength);
}
AnnotateAttr *clone(ASTContext &C) const;
void printPretty(raw_ostream &OS,
const PrintingPolicy &Policy) const;
const char *getSpelling() const;
llvm::StringRef getAnnotation() const {
return llvm::StringRef(annotation, annotationLength);
}
unsigned getAnnotationLength() const {
return annotationLength;
}
void setAnnotation(ASTContext &C, llvm::StringRef S) {
annotationLength = S.size();
this->annotation = new (C, 1) char [annotationLength];
if (!S.empty())
std::memcpy(this->annotation, S.data(), annotationLength);
}
static bool classof(const Attr *A) { return A->getKind() == attr::Annotate; }
};
Destruction of a AnnotateAttr will leak the `annotation` string. So does calls
to `setAnnotation`.
--
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 38835] AnnotateAttr leaks its annotations
https://bugs.llvm.org/show_bug.cgi?id=38835 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- It sure does look like this is a memory leak, but the placement operator new we use here allocates memory from a slab allocator owned by the ASTContext. The memory is freed when the slab allocator is destroyed in the ASTContext destructor. Thank you for the report! -- 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
