[llvm-bugs] [Bug 40858] New: Warn when shadowing a member variable in a structured binding
https://bugs.llvm.org/show_bug.cgi?id=40858
Bug ID: 40858
Summary: Warn when shadowing a member variable in a structured
binding
Product: clang
Version: trunk
Hardware: Macintosh
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++'17
Assignee: unassignedclangb...@nondot.org
Reporter: l...@mrks.info
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
With -Wshadow-all, this should cause a warning (and does in GCC):
struct S {
int i = 1;
void v() {
const auto& [i] = std::tuple{2};
}
};
https://godbolt.org/z/PDVZK1
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40856] Dia2dump dies with stackoverflow on pdbs generated by lld r351376
https://bugs.llvm.org/show_bug.cgi?id=40856 Leonardo Santagada changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Leonardo Santagada --- Yes it seems that was my problem, thanks *** This bug has been marked as a duplicate of bug 40221 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40839] xray convert: catastrophical perf regression
https://bugs.llvm.org/show_bug.cgi?id=40839 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- (In reply to Roman Lebedev from comment #1) > r354764, please backport. Merged in r354856. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40839, which changed state. Bug 40839 Summary: xray convert: catastrophical perf regression https://bugs.llvm.org/show_bug.cgi?id=40839 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40859] New: Tidy up llvm-objcopy error messages
https://bugs.llvm.org/show_bug.cgi?id=40859 Bug ID: 40859 Summary: Tidy up llvm-objcopy error messages Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objcopy Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: alexander.v.shaposhni...@gmail.com, jake.h.ehrl...@gmail.com, jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, ruppre...@google.com We are a bit inconsistent in our error messages in llvm-objcopy. Some examples that I know of: 1) Some end in trailing full stops. Others don't. I think the norm outside the to is to not have full stops, but I don't really mind which it is, as long as it is consistent. 2) Symbol names are sometimes quoted and other times not. Section names are never quoted. I think we should adopt a consistent quoting scheme for both and always use it. Both section and symbol names can theoretically contain spaces (especially if we choose to start printing demangled symbol names at a later point). I'd recommend something like single quotes for symbol names and double quotes for section names, but I'm open to other schemes. 3) Don't know what the state of this one is, but capitalization of the first word in the error message should be identical throughout. I think lower-case is more normal outside the tool, but I'm not sure. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40828] Merge r354721 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40828 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- Merged in r354858. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40828, which changed state. Bug 40828 Summary: Merge r354721 to the 8.0 branch https://bugs.llvm.org/show_bug.cgi?id=40828 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40829, which changed state. Bug 40829 Summary: Merge r354723 to the 8.0 branch https://bugs.llvm.org/show_bug.cgi?id=40829 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40829] Merge r354723 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40829 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r354859. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13419 in oss-fuzz: llvm/clang-fuzzer: ASSERT: DeclAccess != AS_none
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-26 Type: Bug New issue 13419 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: DeclAccess != AS_none https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13419 Detailed report: https://oss-fuzz.com/testcase?key=5712795599896576 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: DeclAccess != AS_none clang::Sema::LookupQualifiedName clang::Sema::CppLookupName Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5712795599896576 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40847, which changed state. Bug 40847 Summary: Merge r354733 into the 8.0 branch : [WebAssembly] Fix select of and (PR40805) https://bugs.llvm.org/show_bug.cgi?id=40847 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40847] Merge r354733 into the 8.0 branch : [WebAssembly] Fix select of and (PR40805)
https://bugs.llvm.org/show_bug.cgi?id=40847 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #2 from Hans Wennborg --- Merged in r354860. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40860] New: git-clang-format updates modified time of unchanged files
https://bugs.llvm.org/show_bug.cgi?id=40860 Bug ID: 40860 Summary: git-clang-format updates modified time of unchanged files Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: arichardson@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Whenever I run git-clang-format followed by ninja, it will recompile all uncommited files even if git-clang-format did not modify any files. It seems like git-clang-format will update the modifiation time even for unchanged files. This is fine for .cpp files but if it touches a commonly used header I then have to recompile effectively all of my project (this can be quite significant for commonly used LLVM headers). It might be possible to write the changed file to a memory buffer, diff that with the on-disk file and only update that file if any changes have been detected. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40861] New: llvm-readobj reads past end of dynamic segment if it does not end in DT_NULL
https://bugs.llvm.org/show_bug.cgi?id=40861 Bug ID: 40861 Summary: llvm-readobj reads past end of dynamic segment if it does not end in DT_NULL Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org Generating a dynamic segment with the following yaml results in there being no DT_NULL entry at the end of the segment: --- !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_EXEC Machine: EM_X86_64 Sections: - Name: .dynamic Type: SHT_DYNAMIC AddressAlign: 0x10 Address: 0x1010 # DT_DEBUG tag only, no DT_NULL tag. Content: "1500" ProgramHeaders: - Type: PT_LOAD VAddr: 0x1000 Sections: - Section: .dynstr - Section: .dynamic - Type: PT_DYNAMIC VAddr: 0x1010 Sections: - Section: .dynamic Although strictly speaking this is illegal, GNU readelf handles it sensibly, because the size is listed in the program header: C:\Work> readelf --dynamic test.tmp.no-null Dynamic section at offset 0x1f0 contains 1 entries: TagType Name/Value 0x0015 (DEBUG) 0x0 However, llvm-readobj does not. It assumes that there is always a trailing DT_NULL entry, and reads past the end of the segment if there is none to find it: C:\Work> llvm-readobj.exe --dynamic-table test.tmp.no-null DynamicSection [ (2 entries) TagType Name/Value 0x0015 DEBUG0x0 0x NULL 0x0 ] I'm guessing, but don't know for sure, that the non-existent NULL entry is printed as such because the next 16 bytes happen to be all 0 in the file. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40862] New: llvm-readobj GNU output for dynamic table does not match GNU readelf output
https://bugs.llvm.org/show_bug.cgi?id=40862 Bug ID: 40862 Summary: llvm-readobj GNU output for dynamic table does not match GNU readelf output Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org There is no distinction between GNU and LLVM style in llvm-readobj's dynamic table. The differences are small, but could be enough to break parsers. It also does not print potentially useful information: GNU readelf output: Dynamic section at offset 0x1f0 contains 2 entries: TagType Name/Value 0x0015 (DEBUG) 0x0 0x (NULL) 0x0 llvm-readelf output: DynamicSection [ (2 entries) TagType Name/Value 0x0015 DEBUG0x0 0x NULL 0x0 ] The important differences are: 1) no offset in the header in llvm-readelf output. 2) square brackets containing the list in llvm-readelf output. 3) Types are not bracketed in llvm-readelf output. There may be others to do with interpretation (e.g. where the value represents a string), but I have not analysed those. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40863] New: cxx_status.html seems out of date on c++ default dialect
https://bugs.llvm.org/show_bug.cgi?id=40863 Bug ID: 40863 Summary: cxx_status.html seems out of date on c++ default dialect Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Documentation Assignee: unassignedclangb...@nondot.org Reporter: russell_gal...@sn.scee.net CC: llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk https://clang.llvm.org/cxx_status.html says: "By default, Clang builds C++ code according to the C++98 standard, with many C++11 features accepted as extensions. You can use Clang in C++11 mode with the -std=c++11 option." As of r320250 this was changed to C++14. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40864] New: Don't abort printing of dynamic table if dynamic string address is invalid
https://bugs.llvm.org/show_bug.cgi?id=40864 Bug ID: 40864 Summary: Don't abort printing of dynamic table if dynamic string address is invalid Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org This issue is similar to, but not the same as bug 40807. For the following yaml input, which contains a DT_STRTAB value pointing well outside the address space, llvm-readobj aborts with "LLVM ERROR: Virtual address is not in any segment". --- !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_EXEC Machine: EM_X86_64 Sections: - Name:.dynamic Type:SHT_DYNAMIC Address: 0x1000 Entries: - Tag: DT_STRTAB Value: 0x200 - Tag: DT_STRSZ Value: 10 - Tag: DT_NEEDED Value: 1 ProgramHeaders: - Type: PT_LOAD VAddr: 0x1000 Sections: - Section: .dynamic - Type: PT_DYNAMIC VAddr: 0x1000 Sections: - Section: .dynamic Better would be to emit a regular error somewhere and not to attempt lookups. This is what GNU readelf does: readelf: Warning: Virtual address 0x200 not located in any PT_LOAD segment. readelf: Error: Unable to determine the length of the dynamic string table Dynamic section at offset 0x1f0 contains 4 entries: TagType Name/Value 0x0005 (STRTAB) 0x200 0x000a (STRSZ) 10 (bytes) 0x0001 (NEEDED) 0x1 0x (NULL) 0x0 (I don't know why it complains about being unable to determine the legnth of the dynamic string table). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37763] [X86] Investigate vectorization of the overflow add/sub nodes to PADD+PADDS+PCMPEQ etc.
https://bugs.llvm.org/show_bug.cgi?id=37763 Simon Pilgrim changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||r354866 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40865] New: [PowerPC64] lld is processing R_PPC64_ADDR64 relocations incorrectly
https://bugs.llvm.org/show_bug.cgi?id=40865 Bug ID: 40865 Summary: [PowerPC64] lld is processing R_PPC64_ADDR64 relocations incorrectly Product: lld Version: unspecified Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: lup...@freebsd.org CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org On PowerPC64, the relocations of FreeBSD kernel modules metadata are not being resolved correctly. For instance, the relocations below end up turning into zeroes, after the final link step: RELOCATION RECORDS FOR [set_modmetadata_set]: OFFSET TYPE VALUE R_PPC64_ADDR64.data 0008 R_PPC64_ADDR64.data+0x0018 But when linking with ld.bfd instead, they are replaced by .data and .data+0x18 addresses. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30241] llvm-objdump -p omits dynamic headers (in comparison to GNU objdump)
https://bugs.llvm.org/show_bug.cgi?id=30241 Xing GUO changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Xing GUO --- fixed in rL354782 and rL354871. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40866] New: Improve error message for malformed ELF
https://bugs.llvm.org/show_bug.cgi?id=40866 Bug ID: 40866 Summary: Improve error message for malformed ELF Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org The error message produced by llvm-readobj when there is a parse failure is unhelpful: "Error reading file: Invalid data was encountered while parsing the file." In the particular case I'm seeing it, the file has been modified such that the offset/size fields of the dynamic segment point after the end of the file. Ideally the error message would say what went wrong specifically, e.g. "PT_DYNAMIC segment does not appear to be wholly within the file. p_offset = 0x1234, p_filesz = 0x4321, file size = 0x1000". -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36991] LLD-linked binary segfaults at runtime on alpine linux
https://bugs.llvm.org/show_bug.cgi?id=36991 Fangrui Song changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED CC||i...@maskray.me --- Comment #11 from Fangrui Song --- Fixed by rL329960 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36991] LLD-linked binary segfaults at runtime on alpine linux
https://bugs.llvm.org/show_bug.cgi?id=36991 Andrew Kelley changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #12 from Andrew Kelley --- Hi Fangrui, According to Reid the fix was reverted in r330164, since it caused many Chromium test binaries to crash on exit. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40867] New: ICE in mangleUnresolvedTypeOrSimpleId
https://bugs.llvm.org/show_bug.cgi?id=40867
Bug ID: 40867
Summary: ICE in mangleUnresolvedTypeOrSimpleId
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: antosh...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following code cause ICE:
template
int is_vector(T const&, decltype(static_cast(0)->~vector())* = 0) {
return 1;
}
template
int is_vector(T const&, decltype(static_cast(0)->~deque())* = 0) {
return 0;
}
template class vector{};
int test() {
return is_vector(vector());
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40813] Crash when trying to get layout information of undeductible auto type
https://bugs.llvm.org/show_bug.cgi?id=40813 Emilio Cobos Álvarez [:emilio] changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Emilio Cobos Álvarez [:emilio] --- Should be fixed now. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40868] New: llvm-readelf should print "" or similar for unknown ELF type field
https://bugs.llvm.org/show_bug.cgi?id=40868 Bug ID: 40868 Summary: llvm-readelf should print "" or similar for unknown ELF type field Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org If you create an ELF with an unknown ELF type e.g: --- !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:0x42 Machine: EM_X86_64 llvm-readelf produces the following output: ELF Header: Type: 42 GNU readelf produces the output as follows: ELF Header: Type: : 42 This is a little clearer, and would be preferable in the LLVM tool too. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11763 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !isUniformAfterVectorization(PredInst, VF) && "Instruction marked uniform-after-
Updates: Labels: Deadline-Approaching Comment #4 on issue 11763 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !isUniformAfterVectorization(PredInst, VF) && "Instruction marked uniform-after- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11763#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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40869] New: [X86] Poor broadcast folding from ext/trunc loads
https://bugs.llvm.org/show_bug.cgi?id=40869
Bug ID: 40869
Summary: [X86] Poor broadcast folding from ext/trunc loads
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: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
e.g. (from vector-shuffle-512-v32.ll)
llc < %s -mtriple=x86_64-apple-darwin -mcpu=skx
define <32 x i16> @insert_dup_elt1_mem_v32i16_i32(i32* %ptr) #0 {
; KNL-LABEL: insert_dup_elt1_mem_v32i16_i32:
; KNL: ## %bb.0:
; KNL-NEXT:vpbroadcastw 2(%rdi), %ymm0
; KNL-NEXT:vmovdqa %ymm0, %ymm1
; KNL-NEXT:retq
;
; SKX-LABEL: insert_dup_elt1_mem_v32i16_i32:
; SKX: ## %bb.0:
; SKX-NEXT:movzwl 2(%rdi), %eax
; SKX-NEXT:vpbroadcastw %eax, %zmm0
; SKX-NEXT:retq
%tmp = load i32, i32* %ptr, align 4
%tmp1 = insertelement <4 x i32> zeroinitializer, i32 %tmp, i32 0
%tmp2 = bitcast <4 x i32> %tmp1 to <8 x i16>
%tmp3 = shufflevector <8 x i16> %tmp2, <8 x i16> undef, <32 x i32>
ret <32 x i16> %tmp3
}
Notice how the KNL (AVX2) version manages to fold but SKX (AVX512BWVL) ymm
broadcasts fail.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40870] New: clang seems limited to uint32 line numbers
https://bugs.llvm.org/show_bug.cgi?id=40870
Bug ID: 40870
Summary: clang seems limited to uint32 line numbers
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: j...@jguk.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Two parts of #line numbers have an issue. So I am filing together.
1) clang seems limited to uint32 line numbers
and then wraparound back to 0 even !
I know many people won't ever encounter this, but good to define it.
Better to change it to 64bit?
If there must be a limit, better to change "directive requires a positive
integer argument" to show the limit
Also better to fix it on the line limit? 4294967295
ie ""directive requires a positive integer argument 1 - 4294967295"
2) #line 0 is not allowed by C spec, but Clang allows it
int main(void)
{
#line 0
#warning msg1
}
from godbolt.org
#1 with x86-64 clang (trunk)
:4294967295:6: warning: msg1 [-W#warnings]
#warning msg1
^
:0:8: error: #line directive requires a positive integer argument
#line 4294967296
^
:1:6: warning: msg2 [-W#warnings]
#warning msg2
^
2 warnings and 1 error generated.
Compiler returned: 1
int main(void)
{
#line 4294967295
#warning msg1
#line 4294967296
#warning msg2
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40871] New: Wrong debug info generated at -O3 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=40871
Bug ID: 40871
Summary: Wrong debug info generated at -O3 (-O0 is correct)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Keywords: wrong-debug
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: cmt...@google.com, dblai...@gmail.com,
echri...@gmail.com, jeremy.morse.l...@gmail.com,
llvm-bugs@lists.llvm.org, v...@apple.com
$ cat outer.c
optimize_me_not() {}
$ cat a.c
int main() {
int k = 0;
for (; k < 1; k++)
;
optimize_me_not();
}
### -O0
(lldb) r
Process 7046 launched: '/home/davide/LLDB-testing/reduce/a.out' (x86_64)
Process 7046 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004004b3 a.out`main at abc.c:5:3
2 int k = 0;
3 for (; k < 1; k++)
4;
-> 5 optimize_me_not();
6}
(lldb) frame var k
(int) k = 1
### -O3
Current executable set to './a.out' (x86_64).
(lldb) br set -p optimize_me_not
Breakpoint 1: where = a.out`main + 1 at abc.c:5:3, address = 0x00400481
(lldb) r
Process 20271 launched: '/home/davide/LLDB-testing/reduce/a.out' (x86_64)
Process 20271 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400481 a.out`main at abc.c:5:3
2 int k = 0;
3 for (; k < 1; k++)
4;
-> 5 optimize_me_not();
6}
(lldb) frame var k
(int) k = 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40872] New: [AMDGPU][MC] Different conversion rules for integer literals and expressions
https://bugs.llvm.org/show_bug.cgi?id=40872 Bug ID: 40872 Summary: [AMDGPU][MC] Different conversion rules for integer literals and expressions Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Currently assembler has different conversion rules for integer literals and expressions which may confuse users. Compare the rules: https://llvm.org/docs/AMDGPUOperandSyntax.html#integer-literals https://llvm.org/docs/AMDGPUOperandSyntax.html#amdgpu-synid-exp-conv For integer literals, assembler checks that the truncated bits are either all zero or all ones. In the latter case the MSB of the result after truncation must be 1. For example, the following code will trigger an error: v_add_f32 v0, 0x101ff00, v0 // error In contrast, expressions are truncated to the expected operand size. No checks are performed: x = 0x101ff00 v_add_f32 v0, x, v0 // assembled ok I believe conversion rules for integer literals and expressions should be as close as possible. There is a similar but different issue (bug 40806 "Different conversion rules for literals and inlinable constants"). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38583] Clarify assumptions of llvm.memcpy/memmove/memset.* when count is 0
https://bugs.llvm.org/show_bug.cgi?id=38583 Kristina Brooks changed: What|Removed |Added Fixed By Commit(s)||rL354911 ||76eb4b02d93b3a7704b496f3e16 ||dd14bf72cb3a9 CC||krist...@nym.hush.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Kristina Brooks --- Landed the documentation updates as r354911 (GitHub monorepo commit 76eb4b02d93b3a7704b496f3e16dd14bf72cb3a9). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40873] New: [AMDGPU][MC] Many operands do not accept constant expressions for unclear reason
https://bugs.llvm.org/show_bug.cgi?id=40873 Bug ID: 40873 Summary: [AMDGPU][MC] Many operands do not accept constant expressions for unclear reason Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Examples: x = 1 v_or3_b32 v1, v2, v3, 1 // ok v_or3_b32 v1, v2, v3, x // error y = 0x11213141 v_madak_f32 v5, v1, v2, 0x11213141 // ok v_madak_f32 v5, v1, v2, y // error A list of known issues: - reg/const (isRegOrInlineNoMods) - reg/lit (isVSrcB64, isVSrcB16, isVSrcF16, isVSrcF16, isVCSrcV2F16 etc) - sopp, sopk 16-bit constants - s_setreg_imm32_b32 32-bit constant - madak fp constants -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40874] New: -Wextra-semi shouldn't report semicolons in macros entirely in system headers
https://bugs.llvm.org/show_bug.cgi?id=40874
Bug ID: 40874
Summary: -Wextra-semi shouldn't report semicolons in macros
entirely in system headers
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Consider this ATL code:
thakis@thakis:~/src/chrome/src$ cat test.cc
#include
#include
class __declspec(uuid("---c000-0046"))
GaiaCredentialProvider {};
EXTERN_C const CLSID CLSID_GaiaCredentialProvider;
class CGaiaCredentialProvider
: public CComObjectRootEx,
public CComCoClass {
public:
DECLARE_NO_REGISTRY()
BEGIN_COM_MAP(CGaiaCredentialProvider)
END_COM_MAP()
};
OBJECT_ENTRY_AUTO(__uuidof(GaiaCredentialProvider), CGaiaCredentialProvider)
thakis@thakis:~/src/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang-cl -c test.cc -imsvc
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/VC/Tools/MSVC/14.16.27023/atlmfc/include
-imsvc
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/win_sdk/Include/10.0.17763.0/ucrt/
-imsvc
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/VC/Tools/MSVC/14.16.27023/include/
-imsvc
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/win_sdk/Include/10.0.17763.0/um
-imsvc
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/win_sdk/Include/10.0.17763.0/shared/
-Wextra-semi
test.cc(20,1): warning: extra ';' outside of a function is incompatible with
C++98 [-Wc++98-compat-extra-semi]
OBJECT_ENTRY_AUTO(__uuidof(GaiaCredentialProvider), CGaiaCredentialProvider)
^
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/VC/Tools/MSVC/14.16.27023/atlmfc/include/atlcom.h(2407,2):
note:
expanded from macro 'OBJECT_ENTRY_AUTO'
OBJECT_ENTRY_PRAGMA(class)
^
third_party/depot_tools/win_toolchain/vs_files/818a152b3f1da991c1725d85be19a0f27af6bab4/VC/Tools/MSVC/14.16.27023/atlmfc/include/atlcom.h(2396,91):
note:
expanded from macro 'OBJECT_ENTRY_PRAGMA'
#define OBJECT_ENTRY_PRAGMA(class) __pragma(comment(linker,
"/include:__pobjMap_" #class));
^
1 warning generated.
-Wextra-semi complains about this, even though no part of the macro expansion
that adds the extra semicolon is in user code. clang shouldn't emit
-Wextra-semi for semicolons are 100% in system headers.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40875] New: [feature suggestion] Please split out dump() and other debug functionality into a separate library
https://bugs.llvm.org/show_bug.cgi?id=40875 Bug ID: 40875 Summary: [feature suggestion] Please split out dump() and other debug functionality into a separate library Product: Runtime Libraries Version: trunk Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: other Assignee: unassignedb...@nondot.org Reporter: y...@tsoft.com CC: llvm-bugs@lists.llvm.org The Intel's ISPC compiler [1] and flang compiler expect dump() function to be present while it is commonly excluded in the packages. LLVM_ENABLE_DUMP is a relevant cmake variable. It is difficult to build LLVM with custom options for individual other projects. Suggested solution: Please add a separate library that would contain functions disabled by LLVM_ENABLE_DUMP=OFF, for example libLLVMDebug.so This library can be installed as a sub-package, or as a separate package, and would eliminate the problem. ---References--- [1] ISPS bug report. https://github.com/ispc/ispc/issues/1427 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37561] [llvm-profdata/llvm-cov] coverage broken for C++ when built with clang-cl
https://bugs.llvm.org/show_bug.cgi?id=37561 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Reid Kleckner --- I straightened out the ?_GErrorInfoBase issue in https://reviews.llvm.org/D58691 / r354924, and the attached test case works now. This issue ended up being several issues in one, so I will close this, and please file any new issues with coverage separately. I expect there will still be some. Thanks for the test case! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40876] New: [aarch64] clang-cl 8.0rc2 generates unwind data that llvm-readelf cannot parse
https://bugs.llvm.org/show_bug.cgi?id=40876 Bug ID: 40876 Summary: [aarch64] clang-cl 8.0rc2 generates unwind data that llvm-readelf cannot parse Product: new-bugs Version: 8.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: froy...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org In: https://github.com/froydnj/aarch64-xdata-bug is an aarch64 windows .obj file, generated by "clang 8.0.0 tags/RELEASE_800/rc2 353414". Running `llvm-readelf -unwind $OBJ` produces an error message: LLVM ERROR: .xdata must be at least 8 bytes in size with truncated output. I'm not sure whether clang is at fault here or whether llvm-readelf is doing the wrong thing. The preprocessed source for the file is included, and cmdline.txt contains the command-line used to compile the file. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36991] LLD-linked binary segfaults at runtime on alpine linux
https://bugs.llvm.org/show_bug.cgi?id=36991 Andrew Kelley changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Andrew Kelley --- Thanks for the clarification! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
