[llvm-bugs] [Bug 35471] copy relocation symbols don't show up in --Map output
https://bugs.llvm.org/show_bug.cgi?id=35471 George Rimar changed: What|Removed |Added Resolution|--- |FIXED CC||gri...@accesssoftek.com Status|NEW |RESOLVED --- Comment #1 from George Rimar --- r319879, r319769 -- 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 35542] New: [OpenMP] reduction on array section produces incorrect result after r316362
https://bugs.llvm.org/show_bug.cgi?id=35542
Bug ID: 35542
Summary: [OpenMP] reduction on array section produces incorrect
result after r316362
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: daniil.si...@intel.com
CC: llvm-bugs@lists.llvm.org
test.c:
==
int printf(const char *, ...);
int main() {
int total[3] = { 0 };
int a[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
#pragma omp parallel for reduction(+:total[1:2])
for (int i = 0; i < 10; i++) {
total[1 + i % 2] += a[i];
}
printf("%d %d %d\n", total[0], total[1], total[2]);
}
===
Before:
$ clang -v
clang version 6.0.0 (trunk 316361)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
$ clang -O0 -fopenmp test.c
$ ./a.out
0 25 30
-
After:
$ clang -v
clang version 6.0.0 (trunk 316362)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
$ clang -O0 -fopenmp test.c
$ ./a.out
0 30 0
r316362 | hahnfeld | 2017-10-23 21:01:35 +0200 (Mon, 23 Oct 2017) | 28 lines
[OpenMP] Avoid VLAs for some reductions on array sections
In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }
For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }
This relands commit r316229 that I reverted in r316235 because it
failed on some bots. During investigation I found that this was because
Clang and GCC evaluate the two arguments to emplace_back() in
ReductionCodeGen::emitSharedLValue() in a different order, hence
leading to a different order of generated instructions in the final
LLVM IR. Fix this by passing in the arguments from temporary variables
that are evaluated in a defined order.
Differential Revision: https://reviews.llvm.org/D39136
--
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 35543] New: Assertion `Ty && "Trying to add a type that doesn't exist?"' failed on Windows self host
https://bugs.llvm.org/show_bug.cgi?id=35543
Bug ID: 35543
Summary: Assertion `Ty && "Trying to add a type that doesn't
exist?"' failed on Windows self host
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: russell_gal...@sn.scee.net
CC: llvm-bugs@lists.llvm.org
At r319883. Found building a Windows self host compiler with debug. Seen on
DeltaAlgorithm.cpp and other files.
Example reduced from DeltaAlgorithm.cpp
$ cat test.cpp
class A {
typedef void _Nodeptr;
};
class B {
A FailedTestsCache;
bool m_fn1();
};
bool B::m_fn1() {}
$ clang++ -cc1 -emit-obj -gcodeview -debug-info-kind=limited -dwarf-version=4
-x c++ test.cpp
test.cpp:8:18: warning: control reaches end of non-void function
bool B::m_fn1() {}
^
clang++: /home/gbgallor/git/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:764: void
llvm::DwarfUnit::addType(llvm::DIE&, const llvm::DIType*,
llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that doesn't
exist?"' failed.
--
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 35544] New: Wasm: add new weak global symbol "__stack_top"
https://bugs.llvm.org/show_bug.cgi?id=35544 Bug ID: 35544 Summary: Wasm: add new weak global symbol "__stack_top" Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: n...@realvnc.com CC: llvm-bugs@lists.llvm.org Could we add a new symbol to those provided by LLD? It should be a weak global integer called "__stack_top" and point to the end of the stack region, as calculated in Writer::layoutMemory. This would be useful in Musl. Currently, when malloc needs to provide fresh pages of memory to the Wasm module, all it knows initially is the size of the allocated region from "__builtin_wasm_current_memory". However, the Wasm page size is large (64KiB) so potentially 64KiB of memory at the end of the current page is unused. It would nice if malloc could start allocating its data right from the top of the stack, instead of wasting space by beginning from the next Wasm page. -- 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] Issue 3368 in oss-fuzz: llvm: ASSERT: BT->isInteger()
Updates: Labels: Deadline-Approaching Comment #4 on issue 3368 by sheriff...@chromium.org: llvm: ASSERT: BT->isInteger() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3368#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3370 in oss-fuzz: llvm: ASSERT: getClient() && "DiagnosticClient not set!"
Updates: Labels: Deadline-Approaching Comment #4 on issue 3370 by sheriff...@chromium.org: llvm: ASSERT: getClient() && "DiagnosticClient not set!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3370#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3369 in oss-fuzz: llvm: Out-of-memory in llvm_clang-format-fuzzer
Updates: Labels: Deadline-Approaching Comment #3 on issue 3369 by sheriff...@chromium.org: llvm: Out-of-memory in llvm_clang-format-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3369#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35517] Delete called in virtual destructor
https://bugs.llvm.org/show_bug.cgi?id=35517 Konstantin Morshnev changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Konstantin Morshnev --- > has a good description of deleting destructors. The description is clear and we know it. But it is about dynamic objects (MyStruct *ss=new MyStruct), and we have a stack object (MyStruct ss). And if you'll and some printfs (like https://godbolt.org/g/fW4QZk) you'll see, that delete is not called. It looks like there are two destructor versions are generated - one with delete call and one without. But if the one with delete is not referenced, why it is not optimized out? > FWIW, your testcase only compiles in GCC 6.1 because they changed their > default standard mode to C++14 Thx for this note. P.S. As a workaround we are temporary disabling virtual destructors to check that build-in delete is not used in our code, but it's not very convenient. -- 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 35546] New: [X86] Warn if a scheduling instregex fails to match any instruction
https://bugs.llvm.org/show_bug.cgi?id=35546 Bug ID: 35546 Summary: [X86] Warn if a scheduling instregex fails to match any instruction Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: andrea.dibia...@gmail.com, andrew.v.tische...@gmail.com, gadi.ha...@intel.com, llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com Blocks: 32325 Working on the scheduler models recently I've noticed several cases where typos in instregex entries have meant it failed to match any instruction. It would be very useful if tablegen reported a warning/error if the instregex fails to match any instruction. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=32325 [Bug 32325] [META][X86] Improve implementation and use of X86 scheduler models -- 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 35547] New: [ThinLTO] multi-threaded use after free when handling error
https://bugs.llvm.org/show_bug.cgi?id=35547
Bug ID: 35547
Summary: [ThinLTO] multi-threaded use after free when handling
error
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: russell_gal...@sn.scee.net
CC: llvm-bugs@lists.llvm.org
While investigating PR35472 we observed some crashes while handling that error.
Building clang and llvm-lto with ASan (r319883) shows that one thread is trying
to access command line options after they have been freed. Note that we do not
see the use-after-free with -threads=1.
$ cat a.cpp
struct Charlie {
__attribute__((__always_inline__)) ~Charlie() { Golf = 0; }
int Golf;
};
struct Delta {
Charlie Foxtrot;
};
struct Echo {
Charlie Foxtrot;
__attribute__((nodebug)) ~Echo() = default;
};
extern void Bravo();
void Bravo() {
Delta Hotel;
Echo India;
}
$ cat b.cpp
extern void Bravo();
extern void Alpha();
void Alpha() { Bravo(); }
$ clang++ -c a.cpp b.cpp --std=c++11 -O0 -g -flto=thin
$ llvm-lto -thinlto-action=run a.o b.o
ThinLTO: b.o: error: Invalid function metadata: outgoing forward refs
(Producer: 'LLVM6.0.0svn' Reader: 'LLVM 6.0.0svn')
LLVM ERROR: importFunctions failed
=
==10367==ERROR: AddressSanitizer: heap-use-after-free on address 0x62404100
at pc 0x0060388d bp 0x7ff7c62fd050 sp 0x7ff7c62fc800
READ of size 32 at 0x62404100 thread T1
#0 0x60388c in __asan_memcpy
.../llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23
#1 0x234da66 in llvm::cl::parser::OptionInfo::OptionInfo(llvm::cl::parser::OptionInfo&&) .../llvm/include/llvm/Support/CommandLine.h:740:9
#2 0x234d8ad in llvm::cl::parser::OptionInfo*
std::__uninitialized_copy::__uninit_copy::OptionInfo*>, llvm::cl::parser::OptionInfo*>(std::move_iterator::OptionInfo*>, std::move_iterator::OptionInfo*>, llvm::cl::parser::OptionInfo*)
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_uninitialized.h:75:3
#3 0x234d481 in
llvm::SmallVectorTemplateBase::OptionInfo, false>::grow(unsigned long)
.../llvm/include/llvm/ADT/SmallVector.h:246:3
#4 0x234d144 in
llvm::SmallVectorTemplateBase::OptionInfo, false>::push_back(llvm::cl::parser::OptionInfo const&) .../llvm/include/llvm/ADT/SmallVector.h:214:13
#5 0x234ce8d in void llvm::cl::parser::addLiteralOption(llvm::StringRef,
llvm::PassInfo const* const&, llvm::StringRef)
.../llvm/include/llvm/Support/CommandLine.h:789:12
#6 0x234c61b in llvm::PassNameParser::passRegistered(llvm::PassInfo const*)
.../llvm/include/llvm/IR/LegacyPassNameParser.h:76:5
#7 0x236b874 in llvm::PassRegistry::registerPass(llvm::PassInfo const&,
bool) .../llvm/lib/IR/PassRegistry.cpp:68:15
#8 0x379b512 in
initializeForceFunctionAttrsLegacyPassPassOnce(llvm::PassRegistry&)
.../llvm/lib/Transforms/IPO/ForceFunctionAttrs.cpp:118:1
#9 0x7ff7ca461a98 in __pthread_once_slow
(/lib/x86_64-linux-gnu/libpthread.so.0+0xea98)
#10 0x6d3b50 in void std::call_once >(std::once_flag&, void*
(&)(llvm::PassRegistry&), std::reference_wrapper&&)
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/mutex:738:17
#11 0x379b452 in
llvm::initializeForceFunctionAttrsLegacyPassPass(llvm::PassRegistry&)
.../llvm/lib/Transforms/IPO/ForceFunctionAttrs.cpp:118:1
#12 0x379b53a in llvm::createForceFunctionAttrsLegacyPass()
.../llvm/lib/Transforms/IPO/ForceFunctionAttrs.cpp:122:14
#13 0x388d9e8 in
llvm::PassManagerBuilder::populateModulePassManager(llvm::legacy::PassManagerBase&)
.../llvm/lib/Transforms/IPO/PassManagerBuilder.cpp:401:11
#14 0x3890826 in
llvm::PassManagerBuilder::populateThinLTOPassManager(llvm::legacy::PassManagerBase&)
.../llvm/lib/Transforms/IPO/PassManagerBuilder.cpp:887:3
#15 0x244586b in (anonymous namespace)::optimizeModule(llvm::Module&,
llvm::TargetMachine&, unsigned int, bool)
.../llvm/lib/LTO/ThinLTOCodeGenerator.cpp:237:7
#16 0x2452b7f in (anonymous namespace)::ProcessThinLTOModule(llvm::Module&,
llvm::ModuleSummaryIndex&, llvm::StringMap&, llvm::TargetMachine&,
llvm::StringMap,
std::allocator > >,
llvm::MallocAllocator> const&, std::unordered_set, std::equal_to, std::allocator > const&, llvm::DenseSet
> const&, llvm::DenseMap, llvm::detail::DenseMapPair > const&, llvm::ThinLTOCodeGenerator::CachingOptions
const&, bool, llvm::StringRef, bool, unsigned int, unsigned int)
.../llvm/lib/LTO/ThinLTOCodeGenerator.cpp:468:3
#17 0x2450e2f in llvm::ThinLTOCodeGenerator::run()::$_5::operator()(int)
const .../llvm/lib/LTO/ThinLTOCodeGenerator.cpp:1011:29
#18 0x24504bf in void std::_Bind::__call(std::tuple<>&&, std::_Index_tuple<0ul>)
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/functional:107
[llvm-bugs] [Bug 35548] New: [X86] Warn if a scheduling instregex doesn't alter the default schedule
https://bugs.llvm.org/show_bug.cgi?id=35548 Bug ID: 35548 Summary: [X86] Warn if a scheduling instregex doesn't alter the default schedule Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: andrea.dibia...@gmail.com, andrew.v.tische...@gmail.com, gadi.ha...@intel.com, llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com Blocks: 32325 Scheduler model instregex entries only need to be added if they alter the behaviour of an instruction's default scheduling class/itinerary. If the instregex is effectively useless, then tablegen should at least emit a debug warning reporting that. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=32325 [Bug 32325] [META][X86] Improve implementation and use of X86 scheduler models -- 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 35549] New: [X86] Repeated schedule comments
https://bugs.llvm.org/show_bug.cgi?id=35549
Bug ID: 35549
Summary: [X86] Repeated schedule comments
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: andrea.dibia...@gmail.com,
andrew.v.tische...@gmail.com, craig.top...@gmail.com,
gadi.ha...@intel.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
Blocks: 32325
Taken from llvm\test\CodeGen\X86\avx512-schedule.ll
declare void @func_f32(float)
define <16 x float> @broadcast_ss_spill(float %x) {
%a = fadd float %x, %x
call void @func_f32(float %a)
%b = insertelement <16 x float> undef, float %a, i32 0
%c = shufflevector <16 x float> %b, <16 x float> undef, <16 x i32>
zeroinitializer
ret <16 x float> %c
}
Note the repeated scheduling comments for vmovaps and vbroadcastss:
llc -mtriple=x86_64-unknown-unknown -print-schedule -mcpu=skx
.text
.file "bar.ll"
.globl broadcast_ss_spill # -- Begin function broadcast_ss_spill
.p2align4, 0x90
.type broadcast_ss_spill,@function
broadcast_ss_spill: # @broadcast_ss_spill
.cfi_startproc
# %bb.0:
subq$24, %rsp # sched: [1:0.25]
.cfi_def_cfa_offset 32
vaddss %xmm0, %xmm0, %xmm0 # sched: [4:0.33]
vmovaps %xmm0, (%rsp) # 16-byte Spill sched: [1:1.00]
# sched: [1:1.00]
callq func_f32
vbroadcastss(%rsp), %zmm0 # 16-byte Folded Reload sched: [8:0.50]
# sched: [8:0.50]
addq$24, %rsp # sched: [1:0.25]
retq# sched: [7:1.00]
func_end0:
.size broadcast_ss_spill, .Lfunc_end0-broadcast_ss_spill
.cfi_endproc
# -- End function
.section".note.GNU-stack","",@progbits
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=32325
[Bug 32325] [META][X86] Improve implementation and use of X86 scheduler models
--
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 35550] New: llvm-pdbutil dump -symbols crash with InlineSiteSym and Inlinee TypeIndex 0x8000002a
https://bugs.llvm.org/show_bug.cgi?id=35550
Bug ID: 35550
Summary: llvm-pdbutil dump -symbols crash with InlineSiteSym
and Inlinee TypeIndex 0x802a
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: sc...@gameranger.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19523
--> https://bugs.llvm.org/attachment.cgi?id=19523&action=edit
gdb_backtrace.txt
Overview: llvm-pdbutil dump -symbols crashes when LazyRandomTypeCollection
tries to allocate an invalid size, due to an InlineSiteSym with an Inlinee
TypeIndex with the high bit set (0x802a).
Steps to Reproduce:
1) PDB file:
http://opensource.spotify.com/cefbuilds/cef_binary_3.2704.1414.g185cd6c_windows32_release_symbols.tar.bz2
(libcef.dll.pdf is roughly 1GB after expanding)
2) llvm-pdbutil dump -symbols libcef.dll.pdb > libcef.dll.pdb.symbols
Actual Results: llvm-pdbutil crashes with a bad-alloc. The
libcef.dll.pdb.symbols file size is 86896 bytes at this point.
The last lines in the output file before the crash are:
Mod 9026 | `obj\base\strings\base.utf_string_conversions.obj`:
4 | S_OBJNAME [size = 100] sig=0,
`y:\work\cef3_git\chromium\src\out\release\obj\base\strings\base.utf_string_conversions.obj`
104 | S_COMPILE3 [size = 60]
machine = intel pentium 3, Ver = Microsoft (R) Optimizing Compiler,
language = c++
frontend = 19.0.23918.0, backend = 19.0.23918.0
flags = ltcg | security checks
164 | S_BUILDINFO [size = 8] BuildId = `0x142AB8`
172 | S_GPROC32 [size = 212]
`std::basic_string,std::allocator
>::basic_string,std::allocator
>`
parent = 0, end = 800, addr = 0001:575872, code size = 52
type = `0x7D9F (void std::basic_string = {Kind = 0x114d}, Parent = 0xac, End = 0x2a8,
Inlinee = {
static FirstNonSimpleIndex = 0x1000, static SimpleKindMask = 0xff, static
SimpleModeMask = 0x700, Index = {Value = {buffer = {0x2a, 0x0, 0x0, 0x80,
AnnotationData = std::vector of length 16, capacity 16 = {0x6, 0x2, 0xc, 0x2,
0x5, 0x6, 0x3, 0xc, 0x7, 0xd, 0x6, 0x2, 0xc, 0xa, 0xa, 0x0}, RecordOffset =
0x0}
(gdb) print /x (uint32_t) IS.Inlinee.Index
$2 = 0x802a
>From a quick look through Microsoft's cvinfo.h, it looks like this is actually
a FuncId / DecoratedItemId:
typedef struct INLINESITESYM {
unsigned short reclen;// Record length
unsigned short rectyp;// S_INLINESITE
unsigned long pParent; // pointer to the inliner
unsigned long pEnd; // pointer to this block's end
CV_ItemId inlinee; // CV_ItemId of inlinee
unsigned char binaryAnnotations[CV_ZEROLEN]; // an array of compressed
binary annotations.
} INLINESITESYM;
// Combined encoding of TI or FuncId, In compiler implementation
// Id prefixed by 1 if it is function ID.
typedef struct DecoratedItemId
{
DecoratedItemId(bool isFuncId, CV_ItemId inputId) {
if (isFuncId) {
decoratedItemId = 0x8000 | inputId;
} else {
decoratedItemId = inputId;
}
}
DecoratedItemId(CV_ItemId encodedId) {
decoratedItemId = encodedId;
}
operator unsigned int() {
return decoratedItemId;
}
bool IsFuncId()
{
return (decoratedItemId & 0x8000) == 0x8000;
}
CV_ItemId GetItemId()
{
return decoratedItemId & 0x7fff;
}
private:
unsigned int decoratedItemId;
} DecoratedItemId;
--
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 35517] Delete called in virtual destructor
https://bugs.llvm.org/show_bug.cgi?id=35517 Richard Smith changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Richard Smith --- The deleting destructor is not optimized out because it's referenced by the 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 35542] [OpenMP] reduction on array section produces incorrect result after r316362
https://bugs.llvm.org/show_bug.cgi?id=35542 Jonas Hahnfeld changed: What|Removed |Added Status|ASSIGNED|RESOLVED Fixed By Commit(s)||r319931 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35537, which changed state. Bug 35537 Summary: Merge r312509 into the 5.0 branch : NewGVN: Fix PR 34452 by passing instruction all the way down when we do aggregat https://bugs.llvm.org/show_bug.cgi?id=35537 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 35537] Merge r312509 into the 5.0 branch : NewGVN: Fix PR 34452 by passing instruction all the way down when we do aggregat
https://bugs.llvm.org/show_bug.cgi?id=35537 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r312509 |r312509 r319952 Status|NEW |RESOLVED --- Comment #7 from Tom Stellard --- Merged: r319952 -- 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 35552] New: [ThinLTO] Incautious error handling
https://bugs.llvm.org/show_bug.cgi?id=35552 Bug ID: 35552 Summary: [ThinLTO] Incautious error handling Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Bitcode Reader Assignee: unassignedb...@nondot.org Reporter: paul_robin...@playstation.sony.com CC: llvm-bugs@lists.llvm.org While investigating PR35472, we occasionally got a different error, "can't create module summary index for buffer: Invalid bitcode signature" followed by a crash. ThinLTOCodeGenerator::linkCombinedIndex() nominally returns a std::unique_ptr, however if readModuleSummaryIndex() returns an error (e.g., Invalid bitcode signature), linkCombinedIndex() can return nullptr. ThinLTOCodeGenerator::run() has this code: // Sequential linking phase auto Index = linkCombinedIndex(); ... Index->collectDefinedGVSummariesPerModule(ModuleToDefinedGVSummaries); That is, there's no null check, and the nullptr causes the inevitable segfault. I figured I'd let the ThinLTO experts decide how they want to handle this. -- 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 35553] New: Dummy sections should be NOBITS
https://bugs.llvm.org/show_bug.cgi?id=35553
Bug ID: 35553
Summary: Dummy sections should be NOBITS
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: jakehehrl...@google.com
CC: llvm-bugs@lists.llvm.org
When given a linker script that creates a section with no input sections and no
byte commands the linker should make the output section have type NOBITS to
reduce the size of the final executable (assuming that the NOBITS sections
occur at the end of the segment). Right now LLD produces PROGBITS sections in
this case.
I thought it would be simple to simply make the default output section type be
NOBITS and then change the type to PROGBITS during finalization if a byte
command was seen but this leads to more complicated issues in
test/ELF/linkerscript/extend-pt-load.s and my naive attempt to fix that caused
other problems in test/ELF/linkerscript/orphan-discard.s. Looking in to this
the issue seems more complicated than I gave it credit for.
Steps to reproduce:
test.ll```
SECTIONS {
.foo : {
. += 0x1000;
}
}
```
test.s```
.global _start
.type _start, STT_FUNC
_start:
ret
```
Then run the following
```
lld --script=test.ll test.o -o test
llvm-readobj -sections test
```
And the .foo section will look like this:
```
Section {
Index: 1
Name: .foo (1)
Type: SHT_PROGBITS (0x1)
Flags [ (0x2)
SHF_ALLOC (0x2)
]
Address: 0x0
Offset: 0x1000
Size: 4096
Link: 0
Info: 0
AddressAlignment: 1
EntrySize: 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 35554] New: Java: clang-format doesn't honor BreakBeforeBraces with @interface declarations
https://bugs.llvm.org/show_bug.cgi?id=35554
Bug ID: 35554
Summary: Java: clang-format doesn't honor BreakBeforeBraces
with @interface declarations
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: chris.a.willi...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Related to #21456.
If defining annotations in Java, we use the @interface keyword designation.
Ideally it would treated similarly to class/interface declarations and would
honor the BreakBeforeBraces setting. However it always uses an Attach style
brace
@Documented
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.FIELD)
public static @interface property
{
}
with BreakBeforeBraces: Allman still produces
@Documented
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.FIELD)
public static @interface property {
}
--
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 18505] Missing support for APCS frame layout
https://bugs.llvm.org/show_bug.cgi?id=18505 Evgenii Stepanov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Evgenii Stepanov --- Anyway, there is nothing left to be done on the LLVM side, so I'm closing this bug. -- 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 35490] llvm-cov: Wrong coverage with multiple binaries and shared code
https://bugs.llvm.org/show_bug.cgi?id=35490 Vedant Kumar changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Vedant Kumar --- The root cause here is the same as the one in PR35459. The coverage reader thinks there is just one canonical record for w(), because it incorrectly assumes the ODR holds across multiple binaries. It cannot treat multiple records for w() additively. The two records for w() (one from 'x' and one from 'y') have the same hash, which explains why you only see the hash mismatch warning when one of the definitions are changed. *** This bug has been marked as a duplicate of bug 35459 *** -- 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 35495] [LLVM-COV] statement inside a label after a non-executed statement is wrongly marked as non executed in llvm-cov
https://bugs.llvm.org/show_bug.cgi?id=35495 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vedant Kumar --- Thanks for the report! Fixed in r319990. -- 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 35493] [LLVM-COV] statements after two labels and '||' operator are wrongly marked as not executed in llvm-cov
https://bugs.llvm.org/show_bug.cgi?id=35493 Vedant Kumar changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Vedant Kumar --- This was just fixed (see llvm.org/PR35495). *** This bug has been marked as a duplicate of bug 35495 *** -- 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 35164] WASM: Assertion taking address of struct (unknown size)
https://bugs.llvm.org/show_bug.cgi?id=35164 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||dan433...@gmail.com --- Comment #2 from Dan Gohman --- Looks good! Committed in r319991. -- 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 35205] Invalid WebAssembly module generation when using alloca
https://bugs.llvm.org/show_bug.cgi?id=35205 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dan Gohman --- As of r319810, we now emit mutable imports. So the current state is that .o files are still not valid according to the current wasm spec, but they anticipate a feature expected to be added. In particular, wabt has recently enabled support for mutable imports as part of --enable-threads. -- 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 35555] New: SEGV in FormatASTNodeDiagnosticArgument()
https://bugs.llvm.org/show_bug.cgi?id=3
Bug ID: 3
Summary: SEGV in FormatASTNodeDiagnosticArgument()
Product: new-bugs
Version: 5.0
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ema...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Created attachment 19524
--> https://bugs.llvm.org/attachment.cgi?id=19524&action=edit
reproducer
Raw reproducer attached, will try reducing
(lldb) bt
* thread #1, name = 'c++', stop reason = signal SIGSEGV
* frame #0: 0x0155c84a c++`::FormatASTNodeDiagnosticArgument() at
ASTDiagnostic.cpp:396
frame #1: 0x02516403 c++`::FormatDiagnostic() [inlined]
ConvertArgToString at Diagnostic.h:701
frame #2: 0x025163a8 c++`::FormatDiagnostic() at Diagnostic.cpp:895
frame #3: 0x024e49c2 c++`::HandleDiagnostic() at
TextDiagnosticPrinter.cpp:118
frame #4: 0x01fac1bc c++`::ProcessDiag() [inlined] EmitDiag at
DiagnosticIDs.cpp:694
frame #5: 0x01fac19b c++`::ProcessDiag() at DiagnosticIDs.cpp:686
frame #6: 0x02515ed0 c++`::EmitCurrentDiagnostic() [inlined]
ProcessDiag at Diagnostic.h:879
frame #7: 0x02515ec5 c++`::EmitCurrentDiagnostic() at
Diagnostic.cpp:418
frame #8: 0x01633b70 c++`::EmitCurrentDiagnostic() at Sema.cpp:1142
frame #9: 0x01add31e c++`::BuildLambdaExpr() at SemaLambda.cpp:1530
frame #10: 0x01adcf87 c++`::ActOnLambdaExpr() at
SemaLambda.cpp:1424
frame #11: 0x01c536ba c++`::ParseLambdaExpressionAfterIntroducer()
at ParseExprCXX.cpp:1300
frame #12: 0x01c51f36 c++`::ParseLambdaExpression() at
ParseExprCXX.cpp:685
frame #13: 0x01c60eaa c++`::ParseCastExpression() at
ParseExpr.cpp:1411
frame #14: 0x01c59f35 c++`::ParseAssignmentExpression() [inlined]
ParseCastExpression at ParseExpr.cpp:521
frame #15: 0x01c59f23 c++`::ParseAssignmentExpression() at
ParseExpr.cpp:168
frame #16: 0x01c3b34a
c++`::ParseDeclarationAfterDeclaratorAndAttributes() [inlined] ParseInitializer
at Parser.h:1679
frame #17: 0x01c3b336
c++`::ParseDeclarationAfterDeclaratorAndAttributes() at ParseDecl.cpp:2216
frame #18: 0x01c397ca c++`::ParseDeclGroup() at ParseDecl.cpp:2006
frame #19: 0x01c35663 c++`::ParseSimpleDeclaration() at
ParseDecl.cpp:1738
frame #20: 0x01c35247 c++`::ParseDeclaration() at Parser.h:0
frame #21: 0x01c7e6ef
c++`::ParseStatementOrDeclarationAfterAttributes() at ParseStmt.cpp:214
frame #22: 0x01c7e34c c++`::ParseStatementOrDeclaration() at
ParseStmt.cpp:110
frame #23: 0x01c85239 c++`::ParseCompoundStatementBody() at
ParseStmt.cpp:1001
frame #24: 0x01c85aff c++`::ParseFunctionStatementBody() at
ParseStmt.cpp:1967
frame #25: 0x01be50a4 c++`::ParseFunctionDefinition() at
Parser.cpp:1212
frame #26: 0x01c396d4 c++`::ParseDeclGroup() at ParseDecl.cpp:1953
frame #27: 0x01be4521 c++`::ParseDeclOrFunctionDefInternal() at
Parser.cpp:979
frame #28: 0x01be3e7f c++`::ParseDeclarationOrFunctionDefinition()
at Parser.cpp:995
frame #29: 0x01be2eca c++`::ParseExternalDeclaration() at
Parser.cpp:845
frame #30: 0x01c196f7 c++`::ParseInnerNamespace() at
ParseDeclCXX.cpp:220
frame #31: 0x01c18fa5 c++`::ParseNamespace() at
ParseDeclCXX.cpp:195
frame #32: 0x01c35112 c++`::ParseDeclaration() at ParseDecl.cpp:0
frame #33: 0x01be248d c++`::ParseExternalDeclaration() [inlined]
SourceLocation at SourceLocation.h:98
frame #34: 0x01be2472 c++`::ParseExternalDeclaration() at
Parser.cpp:777
frame #35: 0x01be1c15 c++`::ParseTopLevelDecl() at Parser.cpp:613
frame #36: 0x01bdd9d5 c++`::ParseAST() at ParseAST.cpp:147
frame #37: 0x0162258c c++`::Execute() at FrontendAction.cpp:902
frame #38: 0x0236be01 c++`::ExecuteAction() at
CompilerInstance.cpp:980
frame #39: 0x0123673e c++`::ExecuteCompilerInvocation() at
ExecuteCompilerInvocation.cpp:251
frame #40: 0x0122b763 c++`::cc1_main() at cc1_main.cpp:221
frame #41: 0x01233d68 c++`main [inlined] ExecuteCC1Tool at
driver.cpp:306
frame #42: 0x01233d42 c++`main at driver.cpp:387
frame #43: 0x0122b17f c++`_start(ap=,
cleanup=) at crt1.c:72
(lldb) frame sel 0
frame #0: 0x0155c84a c++`::FormatASTNodeDiagnosticArgument() at
ASTDiagnostic.cpp:396
393 Qualified = false;
394}
395const NamedDecl *ND = reinterpret_cast(Val);
-> 396ND->getNameForDiagnostic(OS, Context.getPrintingPolicy(),
Qualified);
397break;
398 }
399 case DiagnosticsEngine::ak_nestednamespec: {
--
[llvm-bugs] [Bug 35556] New: [LLVM-COV] dead label and false conditional lead to incorrect coverage in llvm-cov
https://bugs.llvm.org/show_bug.cgi?id=35556
Bug ID: 35556
Summary: [LLVM-COV] dead label and false conditional lead to
incorrect coverage in llvm-cov
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 6.0.0-svn319926-1~exp1 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat small.c
int main()
{
int i = 0;
if (1)
{
goto lbl;
lbl_dead:
i++;
lbl:
if (0)
;
i++;
}
}
$ clang -w -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov; cat small.gcov
1| |int main()
2| 1|{
3| 1|int i = 0;
4| 1|if (1)
5| 1|{
6| 1|goto lbl;
7| 0|lbl_dead:
8| 0|i++;
9| 1|lbl:
10| 1|if (0)
11| 0|;
12| 0|i++;
13| 0|}
14| 1|}
As we can find that, Line #12 was wrongly marked as not executed.
--
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
