[llvm-bugs] [Bug 45336] New: Output sections marked NOLOAD with no input sections are given type SHT_PROGBITS
https://bugs.llvm.org/show_bug.cgi?id=45336
Bug ID: 45336
Summary: Output sections marked NOLOAD with no input sections
are given type SHT_PROGBITS
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: schultetw...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
lld will ignore the NOLOAD annotation of output sections which have no
associated inputs sections.
Repro steps
1. Create a linker script with two output sections. One that contains an input
section and one that contains no input sections. The later should be marked as
NOLOAD.
```bash
echo "SECTIONS {
.text : { *(.text) }
.data_noload (NOLOAD) : { . += 1; }
};" > tmp.script
```
2. Create an output object which has some data in it
```bash
echo ".section .text,\"ax\",@progbits
nop" > tmp.asm
llvm-mc -filetype=obj -triple=x86_64-unknown-linux tmp.asm -o tmp.o
```
3) Link the object file using the script
```bash
ld.lld -o tmp --script tmp.script tmp.o
```
4) Use readelf to dump the sections
```bash
llvm-readelf tmp -S -l
```
I expect to see .data_noload marked as NOBITS but instead I see it marked as
PROGBITS.
--
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 45303] __builtin_thread_pointer makes clang crash
https://bugs.llvm.org/show_bug.cgi?id=45303 Kamlesh Kumar 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 21448 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: Use-of-uninitialized-value in llvm::TargetOptions::ShouldEmitDebugEntryValues
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-Medium Reported-2020-03-28 Type: Bug-Security New issue 21448 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--wasm32-O2: Use-of-uninitialized-value in llvm::TargetOptions::ShouldEmitDebugEntryValues https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21448 Detailed Report: https://oss-fuzz.com/testcase?key=5693528329158656 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: llvm::TargetOptions::ShouldEmitDebugEntryValues llvm::DwarfDebug::DwarfDebug llvm::AsmPrinter::doInitialization Sanitizer: memory (MSAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202003270244:202003280243 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5693528329158656 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45305] fold away float to double promotion in signbit
https://bugs.llvm.org/show_bug.cgi?id=45305 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||0f56bbc1a5b2 Resolution|--- |FIXED --- Comment #3 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rG0f56bbc1a5b2 -- 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 21468 in oss-fuzz: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::DiagnoseUnexpandedParameterPack
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-03-28 Type: Bug New issue 21468 by ClusterFuzz-External: llvm:clang-fuzzer: Null-dereference READ in clang::Sema::DiagnoseUnexpandedParameterPack https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21468 Detailed Report: https://oss-fuzz.com/testcase?key=5157853330669568 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: clang::Sema::DiagnoseUnexpandedParameterPack clang::Sema::ActOnBaseSpecifier clang::Parser::ParseBaseSpecifier Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003270244:202003280243 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5157853330669568 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 45273, which changed state. Bug 45273 Summary: DWARF breaks garbage collection in PE/COFF https://bugs.llvm.org/show_bug.cgi?id=45273 What|Removed |Added Status|RESOLVED|REOPENED 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 45273] DWARF breaks garbage collection in PE/COFF
https://bugs.llvm.org/show_bug.cgi?id=45273 Reid Kleckner changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Blocks||45309 --- Comment #10 from Reid Kleckner --- Marked as blocked on the 10.0.1 release bug to ask the question. There is some risk that this change will discard more sections than intended, but that is almost an inherent risk with section GC / dead stripping / OPT:REF. There is always the trivial workaround for users of not using the feature, so I think we should merge it. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=45309 [Bug 45309] [meta] 10.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45336] Output sections marked NOLOAD with no input sections are given type SHT_PROGBITS
https://bugs.llvm.org/show_bug.cgi?id=45336 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Fangrui Song --- Fixed by https://reviews.llvm.org/D76981 fdc41aa22c60958e6b6df461174b814a4aae3384 (lld>=11) -- 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 45337] New: clang-format 7 and later cannot read RawStringFormats from 6.0
https://bugs.llvm.org/show_bug.cgi?id=45337 Bug ID: 45337 Summary: clang-format 7 and later cannot read RawStringFormats from 6.0 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: ron...@rondom.de CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Created attachment 23282 --> https://bugs.llvm.org/attachment.cgi?id=23282&action=edit clang-format-file that works fine with 6.0 but not with later versions Between clang-format 6.0 and 7.0, the format of the RawStringFormats property has changed. Instead of taking a string of one delimiter per list item (key "Delimiter") it takes multiple delimiters as a list (key "Delimiters") per list item in later versions of clang-format. My expectation is that later versions of clang-format can process a .clang-format file produced with an earlier version of clang-format using the --dump-config switch without any manual changes. https://releases.llvm.org/6.0.0/tools/clang/docs/ClangFormatStyleOptions.html#configurable-format-style-options https://releases.llvm.org/7.0.0/tools/clang/docs/ClangFormatStyleOptions.html#configurable-format-style-options To reproduce: = 1. Either a. Produce a .clang-format file using clang-format-6.0 --dump-config b. Create a .clang-format file with the following content (also attached) --- Language: Cpp RawStringFormats: - Delimiter: pb Language: TextProto BasedOnStyle: google ... 2. Run latest clang-format on some file, e.g. clang-format -i main.cpp Actual behaviour: = ~/clang-format-test ❯ clang-format-6.0 -i main.cpp ~/clang-format-test ❯ clang-format-10 -i main.cpp YAML:4:16: error: unknown key 'Delimiter' - Delimiter: pb ^~ Error reading /home/tobii.intra/ag3512/clang-format-test/.clang-format: Invalid argument ~/clang-format-test Expected behaviour: === The latest versionof clang-format should be able to format files just fine using the old .clang-format 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 45338] New: AllowShortIfStatementsOnASingleLine: WithoutElse broken
https://bugs.llvm.org/show_bug.cgi?id=45338
Bug ID: 45338
Summary: AllowShortIfStatementsOnASingleLine: WithoutElse
broken
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: pablomg+l...@eskapa.be
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
$ cat test.cpp
int main() {
if (true) { function(); }
if (true) function();
if (true) { function(); } else function();
if (true) { function(); } else { function(); }
if (true) function(); else function();
if (true) function(); else { function(); }
}
$ clang-format test.cpp -style="{BasedOnStyle: google, BreakBeforeBraces:
Allman, AllowShortBlocksOnASingleLine: Always,
AllowShortIfStatementsOnASingleLine: WithoutElse}"
int main()
{
if (true) { function(); }
if (true) function();
if (true) { function(); }
else
function();
if (true) { function(); }
else
{
function();
}
if (true)
function();
else
function();
if (true)
function();
else
{
function();
}
}
According to the clang-format 11 documentation,
AllowShortIfStatementsOnASingleLine: WithoutElse means the following: "Without
else put short ifs on the same line only if the else is not a compound
statement.". So the expected result should be:
$ clang-format test.cpp -style="{BasedOnStyle: google, BreakBeforeBraces:
Allman, AllowShortBlocksOnASingleLine: Always,
AllowShortIfStatementsOnASingleLine: WithoutElse}"
int main()
{
if (true) { function(); }
if (true) function();
if (true) { function(); }
else
function();
if (true)
{
function();
}
else
{
function();
}
if (true) function();
else
function();
if (true)
function();
else
{
function();
}
}
I don't use BreakBeforeBraces: Attach but it seems broken too:
$ ../bin/clang-format test.cpp -style="{BasedOnStyle: google,
BreakBeforeBraces: Attach, AllowShortBlocksOnASingleLine: Always,
AllowShortIfStatementsOnASingleLine: WithoutElse}"
int main() {
if (true) { function(); }
if (true) function();
if (true) {
function();
} else
function();
if (true) {
function();
} else {
function();
}
if (true)
function();
else
function();
if (true)
function();
else {
function();
}
}
Might be related to bug 25010 (https://bugs.llvm.org/show_bug.cgi?id=25010) 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 45339] New: Support for bitfields in OpenCL
https://bugs.llvm.org/show_bug.cgi?id=45339 Bug ID: 45339 Summary: Support for bitfields in OpenCL Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: OpenCL Assignee: unassignedclangb...@nondot.org Reporter: dr...@jwdt.org CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org Created attachment 23283 --> https://bugs.llvm.org/attachment.cgi?id=23283&action=edit testcase Is there any reasons bitfields are not supported in OpenCL? The attached code gives me the following error message compiled with clang 10 via clang++ -o test -cl-std=clc++ -c test.cl test.cl:12:21: error: bit-fields are not supported in OpenCL unsigned long version : 8;/// bit 0 to 7: header version ^ test.cl:13:21: error: bit-fields are not supported in OpenCL unsigned long headerSize : 8; /// bit 8 to 15: header size ^ test.cl:14:21: error: bit-fields are not supported in OpenCL unsigned long blockLength : 16; /// bit 16 to 31: block length ^ test.cl:15:21: error: bit-fields are not supported in OpenCL unsigned long feeId : 16; /// bit 32 to 47: FEE identifier ^ test.cl:16:21: error: bit-fields are not supported in OpenCL unsigned long priority : 8; /// bit 48 to 55: priority bit ^ test.cl:17:21: error: bit-fields are not supported in OpenCL unsigned long zero0 : 8; /// bit 56 to 63: zeroed ^ test.cl:23:18: error: expected ';' at end of declaration list unsigned in offsetToNext : 16; /// bit 64 to 79: offset to next packet in memory [...] -- 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 45318] unexpected lld error: undefined symbol: clntudp_create
https://bugs.llvm.org/show_bug.cgi?id=45318 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Fangrui Song --- You can get a reproduce file via LLD_REPRODUCE= or -Wl,--reproduce= After deleting the first line --chroot . from response.txt, you can link it with GNU ld. GNU ld errors as well % aarch64-linux-gnu-ld @response.txt -y clntudp_create -y clntudp_create@GLIBC_2.17 --no-undefined aarch64-linux-gnu-ld: tmp/c/lld.error/libsigar.a(sigar_util.o): reference to clntudp_create aarch64-linux-gnu-ld: tmp/c/lld.error/sysroot/lib/libc.so.6: definition of clntudp_create@GLIBC_2.17 aarch64-linux-gnu-ld: tmp/c/lld.error/libsigar.a(sigar_util.o): in function `sigar_rpc_ping': sigar_util.c:(.text+0x11cc): undefined reference to `clntudp_create' aarch64-linux-gnu-ld: sigar_util.c:(.text+0x11dc): undefined reference to `xdr_void' aarch64-linux-gnu-ld: sigar_util.c:(.text+0x11ec): undefined reference to `xdr_void' aarch64-linux-gnu-ld: sigar_util.c:(.text+0x1238): undefined reference to `clnttcp_create' I agree that the 'did you mean: ' diagnostic is confusing. % ld.lld @response.txt -y clntudp_create -y clntudp_create@GLIBC_2.17 --no-undefined tmp/c/lld.error/libsigar.a(sigar_util.o): reference to clntudp_create tmp/c/lld.error/sysroot/lib/libc.so.6: shared definition of clntudp_create@GLIBC_2.17 ld.lld: error: undefined symbol: clntudp_create >>> referenced by sigar_util.c >>> sigar_util.o:(sigar_rpc_ping) in archive >>> tmp/c/lld.error/libsigar.a >>> did you mean: clntudp_create >>> defined in: tmp/c/lld.error/sysroot/lib/libc.so.6 The definition in libc.so.6 is actually 'clntudp_create@GLIBC_2.17' (VERSYM_HIDDEN), not 'clntudp_create' . It cannot resolve an unversioned reference named 'clntudp_create'. This mechanism is a bit obscure but the intention is that the linker should reject it. A proper fix is to annotate the source code with .symver clntudp_create,clntudp_create@GLIBC_2.17 If you don't do that, you can drop -Wl,--no-undefined as a workaround. There is an obscure runtime behavior making this hack work. According to Linux Standard Base 10.7.6 Symbol Resolution: > The object with the reference does not use versioning, while the object with > the definitions does. In this instance, only the definitions with index > numbers 1 and 2 will be used in the reference match, the same identified by > the static linker as the base definition. In cases where the static linker > was not used, such as in calls to dlopen(), a version that does not have the > base definition index shall be acceptable if it is the only version for which > the symbol is defined. GLIBC_2.17 has index number 2 so glibc ld.so can resolve it at runtime. -- 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
