[llvm-bugs] Issue 11252 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Comment #1 on issue 11252 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11252#c1 ClusterFuzz has detected this issue as fixed in range 201811140257:201811150254. Detailed report: https://oss-fuzz.com/testcase?key=5632476035153920 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd967f6f78 Crash State: clang::DeclContext::lookup LookupDirect CppNamespaceLookup Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810160226:201810170227 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811140257:201811150254 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5632476035153920 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 11024 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Timeout in llvm_llvm-special-case-list-fuzzer
Comment #2 on issue 11024 by ClusterFuzz-External: llvm/llvm-special-case-list-fuzzer: Timeout in llvm_llvm-special-case-list-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11024#c2 ClusterFuzz has detected this issue as fixed in range 201811140257:201811150254. Detailed report: https://oss-fuzz.com/testcase?key=566986535282 Project: llvm Fuzzer: libFuzzer_llvm_llvm-special-case-list-fuzzer Fuzz target binary: llvm-special-case-list-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_llvm-special-case-list-fuzzer Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711070608:201711090621 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811140257:201811150254 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=566986535282 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 11252 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11252 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11252#c2 ClusterFuzz testcase 5632476035153920 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 11024 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Timeout in llvm_llvm-special-case-list-fuzzer
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 11024 by ClusterFuzz-External: llvm/llvm-special-case-list-fuzzer: Timeout in llvm_llvm-special-case-list-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11024#c3 ClusterFuzz testcase 566986535282 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 39673] New: -indvars regression after r346397
https://bugs.llvm.org/show_bug.cgi?id=39673
Bug ID: 39673
Summary: -indvars regression after r346397
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 21123
--> https://bugs.llvm.org/attachment.cgi?id=21123&action=edit
reproducer
The regression starts happening with r346397:
Return "[IndVars] Smart hard uses detection"
The patch has been reverted because it ended up prohibiting propagation
of a constant to exit value. For such values, we should skip all checks
related to hard uses because propagating a constant is always profitable.
Differential Revision: https://reviews.llvm.org/D53691
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346397
91177308-0d34-0410-b5e6-96231b3b80d8
If I run
opt -S -o - foo2.ll -indvars
with the patch I get
define i16 @test10() {
entry:
br label %loop1
loop1:; preds = %loop1, %entry
%l1 = phi i16 [ 0, %entry ], [ %l1.add, %loop1 ]
%l1.add = add nuw nsw i16 %l1, 1
%cmp1 = icmp ult i16 %l1.add, 2
br i1 %cmp1, label %loop1, label %loop2.preheader
loop2.preheader: ; preds = %loop1
br label %loop2
loop2:; preds = %loop2,
%loop2.preheader
%k2 = phi i16 [ %k2.add, %loop2 ], [ 182, %loop2.preheader ]
%l2 = phi i16 [ %l2.add, %loop2 ], [ 0, %loop2.preheader ]
%l2.add = add nuw nsw i16 %l2, 1
tail call void @foo(i16 %k2)
%k2.add = add nuw nsw i16 %k2, 1
%cmp2 = icmp ult i16 %l2.add, 2
br i1 %cmp2, label %loop2, label %loop2.end
loop2.end:; preds = %loop2
%k2.add.lcssa = phi i16 [ %k2.add, %loop2 ]
ret i16 %k2.add.lcssa
}
and without it:
define i16 @test10() {
entry:
br label %loop1
loop1:; preds = %loop1, %entry
%l1 = phi i16 [ 0, %entry ], [ %l1.add, %loop1 ]
%l1.add = add nuw nsw i16 %l1, 1
%cmp1 = icmp ult i16 %l1.add, 2
br i1 %cmp1, label %loop1, label %loop2.preheader
loop2.preheader: ; preds = %loop1
br label %loop2
loop2:; preds = %loop2,
%loop2.preheader
%k2 = phi i16 [ %k2.add, %loop2 ], [ 182, %loop2.preheader ]
%l2 = phi i16 [ %l2.add, %loop2 ], [ 0, %loop2.preheader ]
%l2.add = add nuw nsw i16 %l2, 1
tail call void @foo(i16 %k2)
%k2.add = add nuw nsw i16 %k2, 1
%cmp2 = icmp ult i16 %l2.add, 2
br i1 %cmp2, label %loop2, label %loop2.end
loop2.end:; preds = %loop2
%0 = add i16 182, 2
ret i16 %0
}
Note the difference in how the return value is calculated.
I suppose that indvars doesn't consider this to be the constant case that
should always be allowed, but I think it's quite unfortunate if this
simplification isn't done.
--
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 39674] New: [OpenCL C++] ICE on the nested pointer indirection with address space conversion in OpenCL C++ mode
https://bugs.llvm.org/show_bug.cgi?id=39674
Bug ID: 39674
Summary: [OpenCL C++] ICE on the nested pointer indirection
with address space conversion in OpenCL C++ mode
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: anastasia.stul...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Multiple pointer indirection casting isn't working correctly. I.e. the
following program:
kernel void foo(){
__private int** loc;
int** loc_p = loc;
**loc_p = 1;
}
will fail with ICE in C++ mode, but for C it will generate:
bitcast i32* addrspace(4)* %0 to i32 addrspace(4)* addrspace(4)*
and then perform store over pointer in AS 4 (generic). We have now lost the
information that the original pointer was in private AS and that the adjustment
of AS segment has to be performed before accessing memory pointed by the
pointer. Based on the current specification of addrspacecast in
https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction I am not very
clear whether it can be used for this case without any modifications or
clarifications and also what would happen if there are multiple AS mismatches.
C++'s rules assume that qualifiers don't introduce real representation
differences and that operations on qualified types are compatible with
operations on unqualified types. That's not true of qualifiers in general:
address space qualifiers can change representations, ARC qualifiers can have
incompatible semantics, etc. There is no way to soundly implement a conversion
from __private int ** to __generic int **, just there's no way to soundly
implement a conversion from Derived ** to Base **.
Following this logic it seems reasonable to just disallow such conversions in
order to prevent surprising behavior in the program.
See original discussion in https://reviews.llvm.org/D53764
--
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 39675] New: Undefined behavior inside constexpr function
https://bugs.llvm.org/show_bug.cgi?id=39675
Bug ID: 39675
Summary: Undefined behavior inside constexpr function
Product: clang
Version: trunk
Hardware: Other
OS: other
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: oleksandr.yefre...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Bug summary:
I create two functions a() and b().
Both are very similar and both invoke undefined behavior using integer
overflow.
clang compiler is able to optimize both functions (using -03 flag) up to single
constant.
Except constant is different in both cases! This is still acceptable because of
UB.
C++ forbids to invoke UB inside constexpr functions.
When making function a() constexpr compiler fails to compile code as expected
while it continue to compile very similar function b() and evaluates wrong
result.
Expected behavior:
compiler must not compile function b() when it is marked as constexpr because
of UB inside this function..
Sample code is available in compiler explorer at https://godbolt.org/z/tWXnnd
Sample code:
//constexpr
int a()
{
int i = (1 << 30) + ((1 << 30) - 1);
return i*2/2;
}
constexpr
int f(int i)
{
return i*2/2;
}
constexpr
int b()
{
int i = (1 << 30) + ((1 << 30) - 1);
return f(i);
}
--
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 39676] New: clang segfault
https://bugs.llvm.org/show_bug.cgi?id=39676
Bug ID: 39676
Summary: clang segfault
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: fred...@google.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
In file included from source/common/upstream/cds_incremental.cc:11:
In file included from
bazel-out/k8-fastbuild/bin/source/common/config/_virtual_includes/incremental_subscription_factory_lib/common/config/incremental_subscription_factory.h:10:
bazel-out/k8-fastbuild/bin/source/common/config/_virtual_includes/incremental_subscription_lib/common/config/incremental_subscription_impl.h:20:81:
error: expected '{' after base class list
class IncrementalSubscriptionImpl : public
IncrementalSubscription
^
bazel-out/k8-fastbuild/bin/source/common/config/_virtual_includes/incremental_subscription_lib/common/config/incremental_subscription_impl.h:21:114:
error: expected ';' after class
Grpc::TypedAsyncStreamCallbacks
^
;
Stack dump:
0. Program arguments: /usr/local/google/home/fredlas/clang7/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name cds_incremental.cc
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb
-coverage-notes-file
/proc/self/cwd/bazel-out/k8-fastbuild/bin/source/common/upstream/_objs/cds_incremental_lib/cds_incremental.pic.gcno
-resource-dir /usr/local/google/home/fredlas/clang7/lib/clang/7.0.0
-dependency-file
bazel-out/k8-fastbuild/bin/source/common/upstream/_objs/cds_incremental_lib/cds_incremental.pic.d
-MT
bazel-out/k8-fastbuild/bin/source/common/upstream/_objs/cds_incremental_lib/cds_incremental.pic.o
-sys-header-deps -iquote . -iquote bazel-out/k8-fastbuild/genfiles -iquote
bazel-out/k8-fastbuild/bin -iquote external/bazel_tools -iquote
bazel-out/k8-fastbuild/genfiles/external/bazel_tools -iquote
bazel-out/k8-fastbuild/bin/external/bazel_tools -iquote
external/com_google_absl -iquote
bazel-out/k8-fastbuild/genfiles/external/com_google_absl -iquote
bazel-out/k8-fastbuild/bin/external/com_google_absl -iquote
external/com_github_gabime_spdlog -iquote
bazel-out/k8-fastbuild/genfiles/external/com_github_gabime_spdlog -iquote
bazel-out/k8-fastbuild/bin/external/com_github_gabime_spdlog -iquote
external/com_github_fmtlib_fmt -iquote
bazel-out/k8-fastbuild/genfiles/external/com_github_fmtlib_fmt -iquote
bazel-out/k8-fastbuild/bin/external/com_github_fmtlib_fmt -iquote
external/com_google_protobuf -iquote
bazel-out/k8-fastbuild/genfiles/external/com_google_protobuf -iquote
bazel-out/k8-fastbuild/bin/external/com_google_protobuf -iquote
external/envoy_deps -iquote bazel-out/k8-fastbuild/genfiles/external/envoy_deps
-iquote bazel-out/k8-fastbuild/bin/external/envoy_deps -iquote
external/envoy_api -iquote bazel-out/k8-fastbuild/genfiles/external/envoy_api
-iquote bazel-out/k8-fastbuild/bin/external/envoy_api -iquote
external/com_github_gogo_protobuf -iquote
bazel-out/k8-fastbuild/genfiles/external/com_github_gogo_protobuf -iquote
bazel-out/k8-fastbuild/bin/external/com_github_gogo_protobuf -iquote
external/googleapis -iquote bazel-out/k8-fastbuild/genfiles/external/googleapis
-iquote bazel-out/k8-fastbuild/bin/external/googleapis -iquote
external/com_lyft_protoc_gen_validate -iquote
bazel-out/k8-fastbuild/genfiles/external/com_lyft_protoc_gen_validate -iquote
bazel-out/k8-fastbuild/bin/external/com_lyft_protoc_gen_validate -iquote
external/com_github_cyan4973_xxhash -iquote
bazel-out/k8-fastbuild/genfiles/external/com_github_cyan4973_xxhash -iquote
bazel-out/k8-fastbuild/bin/external/com_github_cyan4973_xxhash -iquote
external/com_github_tencent_rapidjson -iquote
bazel-out/k8-fastbuild/genfiles/external/com_github_tencent_rapidjson -iquote
bazel-out/k8-fastbuild/bin/external/com_github_tencent_rapidjson -iquote
external/com_github_circonus_labs_libcircllhist -iquote
bazel-out/k8-fastbuild/genfiles/external/com_github_circonus_labs_libcircllhist
-iquote
bazel-out/k8-fastbuild/bin/external/com_github_circonus_labs_libcircllhist
-isystem external/com_github_gabime_spdlog/include -isystem
bazel-out/k8-fastbuild/genfiles/external/com_github_gabime_
[llvm-bugs] [Bug 39677] New: clang-format inserts spurious Carriage Returns in C-style block comment
https://bugs.llvm.org/show_bug.cgi?id=39677 Bug ID: 39677 Summary: clang-format inserts spurious Carriage Returns in C-style block comment Product: new-bugs Version: 6.0 Hardware: All OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mark.lan...@beamdog.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21126 --> https://bugs.llvm.org/attachment.cgi?id=21126&action=edit Example Code **Issue** When clang-format is run on a C/C++ file with a C-style block comment, if the block comment contains a non-empty line with only spaces/tabs on it, and the file uses CRLF line endings, then that line will have a naked Carriage Return appended to it. Each time clang-format is run on the document an additional Carriage Return will be added in this way. **More Details** The issue seems to occur with any .clang-format settings that I try, and will never occur with Unix style line endings. Tested with version 6.0.1 and 8.0.0, issues occurs on both. **Example** See attached test.cpp. Run clang-format -i test.cpp on it without a .clang-format file present. **Expected behavior** The line with only 4 spaces on it is cleared (or preserved, I don't know what the default behavior is supposed to be). **Observed behavior** The line with only 4 spaces on it is preserved, and an additional Carriage Return character is added after the 4 spaces. **Probable cause** I'm guessing that there's a `substring(start of line, LF character)` used in this case that catches the Carriage Return character as part of the line in files with CRLF line endings. -- 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 10044 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Parser::SkipUntil
Updates: Labels: Deadline-Approaching Comment #2 on issue 10044 by sheriff...@chromium.org: llvm/clang-fuzzer: Stack-overflow in clang::Parser::SkipUntil https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10044#c2 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 37731] llvm.experimental.vector.reduce.xor and a extractelement+xors produce different code
https://bugs.llvm.org/show_bug.cgi?id=37731 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||346970 --- Comment #6 from Simon Pilgrim --- rL346970 -- 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 39675] Undefined behavior inside constexpr function
https://bugs.llvm.org/show_bug.cgi?id=39675
David Blaikie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
CC||dblai...@gmail.com
--- Comment #2 from David Blaikie ---
As Eli mentioned - this is ill-formed, no diagnostic required. So Clang is
conforming here.
To see the error/reach the invalid case that Clang must diagnose/not accept,
you'd need to call the function in a constexpr context.
For instance, add "constexpr int i = b();" to main (or anywhere else) and clang
will diagnose this:
:23:19: error: constexpr variable 'i' must be initialized by a constant
expression
constexpr int i = b();
^ ~~~
:11:13: note: value 4294967294 is outside the range of representable
values of type 'int'
return i*2/2;
^
:18:12: note: in call to 'f(2147483647)'
return f(i);
^
:23:23: note: in call to 'b()'
constexpr int i = b();
^
https://godbolt.org/z/aSNE9N
For further, the following is a valid constexpr function that must not be
diagnosed at the point of definition:
constexpr int i(bool b) { if (b) return 3/0; return 1; }
'constexpr' doesn't guarantee that all callers can (nor must) be evaluated as a
constant. Just that some callers may. And that all of /those/ callers (the ones
in a constexpr context) must do so in a way that is well defined.
So I can write "int x[i(false)];" and get an array of length 1 - this program
is still totally conforming.
If I write "int x[i(true)];" the compiler is required to reject this program.
If I write "int x = i(true);" the program has UB and the compiler isn't
required to do anything in particular (it's not required to reject the program,
it's not required to make the program do any .particular thing, etc)
--
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 39678] New: Problems with dynamic section entries
https://bugs.llvm.org/show_bug.cgi?id=39678 Bug ID: 39678 Summary: Problems with dynamic section entries Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: bztem...@gmail.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Hi, I had issues with my run-time linker when I used ELF64 files linked by lld. I've debugged my code and it turned out it was reading beyond the relocation entries, outside of the relocation record section. So I've cross-referenced the ELF outputs created by GNU ld and LLVM lld on two architectures, x86_64 and AArch64. Let me share my findings with you, maybe it's useful. I've attached the readelf output in all four cases, but I'll summarize it up. First of all, the .rela.dyn section is good in all four cases. But unfortunately my run-time linker can't use sections, it has to use the dynamic entries (DT_*) referenced from program headers, and that has some inconsistencies (for both GNU ld and LLVM lld). GNU ld and x86_64: .rela.dyn is at 0xf220 - 0xf42e. RELA points to 0xf220 which is correct, and it's size is 24, also correct (has only one entry). JMPREL points to the same address which is not correct (it should point to the first JUMP_SLOT), the size is also not correct, because RELA+RELASZ+PLTRELSZ is bigger than 0xf42e. That doesn't really matter because JMPREL+PLTRELSZ is 0xf42e which is correct. LLVM lld and x86_64: .rela.dyn is at 0xf1a0 - 0xf728. RELA points to 0xf1a0 which is correct, but it's size covers the entire section, which is not. Unlike with GNU ld, JMPREL points correctly to the first JUMP_SLOT, but again, it's size is the size of the entire rela section. This is not good, because both RELA+RELASZ+PLTRELSZ and JMP+PLTRELSZ is bigger than 0xf728, causing reading relocation entries outside of .rela.dyn. GNU ld and AArch64: .rela.dyn is at 0x10bd0 - 0x11200. This is as the book says, surprisingly everything is correct. RELA points to 0x10bd0, and RELA+RELASZ equals to JMPREL which also points to the first JUMP_SLOT. Also RELA+RELASZ+PLTRELSZ=0x11200 and JMPREL+PLTRELSZ=0x11200 which equals to the end of .rela.dyn correctly. LLVM lld and AArch64: .rela.dyn is at 0x14b10 - 0x151b8. Just like with x86_64, RELA and JMPREL are correct, but their sizes are not. Both RELA+RELASZ+PLTRELSZ and JMPREL+PLTRELSZ points beyond the end of .rela.dyn section, causing reading reloaction entries outside .rela.dyn section. Conclusion: at a minimum, I think PLTRELSZ must be corrected, so that JMPREL+PLTRELSZ would not point beyond the end of .rela.dyn section. Hope you'll find my test results useful, bzt X86_64 --- --- GCC / ld --- [ 6] .rela.dyn RELA f220 f220 02e8 0018 A 4 0 8 Dynamic section at offset 0x10110 contains 16 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so] 0x0010 (SYMBOLIC) 0x0 0x000c (INIT) 0x100 0x0004 (HASH) 0xe868 0x0005 (STRTAB) 0xf008 0x0006 (SYMTAB) 0xea08 0x000a (STRSZ) 534 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0003 (PLTGOT) 0x10008 0x0002 (PLTRELSZ) 744 (bytes) 0x0014 (PLTREL) RELA 0x0017 (JMPREL) 0xf220 0x0007 (RELA) 0xf220 0x0008 (RELASZ) 24 (bytes) 0x0009 (RELAENT)24 (bytes) 0x (NULL) 0x0 Relocation section '.rela.dyn' at offset 0xf220 contains 31 entries: Offset Info Type Sym. ValueSym. Name + Addend 0001 00130006 R_X86_64_GLOB_DAT _debug + 0 00010020 00010007 R_X86_64_JUMP_SLO getuidp + 0 00010028 00020007 R_X86_64_JUMP_SLO strcpy + 0 --- Clang / lld --- [ 5] .rela.dyn RELA f1a0 f1a0 0588 0018 A 3 0 8 Dynamic section at offset 0x101f0 contains 17 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so] 0x001e (FLAGS) SYMBOLIC 0x0007 (RELA) 0xf1a0 0x0008 (RELASZ) 1416 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ff9 (RELACOUNT) 27 0x0017 (JMPREL) 0xf440 0x0002 (PLTRELSZ) 1416
[llvm-bugs] [Bug 37432] OUTPUT_FORMAT from linker script doesn't override the -m flag
https://bugs.llvm.org/show_bug.cgi?id=37432 Dmitry Golovin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dmitry Golovin --- With OUTPUT_FORMAT support added to LLD it was possible to link realmode.elf and setup.elf with the latest nightly build (and without adding extra -m to LDFLAGS). -- 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 39679] New: Disabling fp-contraction doesn't work. [#pragma clang fp contract(off)]
https://bugs.llvm.org/show_bug.cgi?id=39679 Bug ID: 39679 Summary: Disabling fp-contraction doesn't work. [#pragma clang fp contract(off)] Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: gui...@berkeley.edu CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Trying to prevent contracting (*,+) into an FMA operation (to guarantee cross_product(a, a) == 0). I add '#pragma clang fp contract(off)' to the start of a block, compiler accepts the pragma, but still generates an FMA instruction. Example at: godbolt.org/z/Cg8rYi Thanks. -- 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 39680] New: Clang doesn't mix static and dynamic initialization of objects
https://bugs.llvm.org/show_bug.cgi?id=39680
Bug ID: 39680
Summary: Clang doesn't mix static and dynamic initialization of
objects
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: dma...@mozilla.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
When a global is initialized with compile-time values but does non-constexpr
work in its constructor, MSVC will bake the compile-time values into the object
to minimize the runtime work.
Clang sets all the fields in the constructor. This can lead to lengthy static
initializers when the objects are large or numerous:
https://bugzilla.mozilla.org/show_bug.cgi?id=1506763
// --
void (*Log)(void*);
struct Entry
{
Entry(int _a, int _b, int _c, int _d)
: a(_a), b(_b), c(_c), d(_d)
{
Log(this);
}
int a, b, c, d;
};
static const Entry myentry { 0, 1, 2, 3 };
int main(int argc, char** argv)
{
return myentry.a;
}
// --
> cl -Z7 -O2 -c x.cpp
> link -debug x.obj
The members are already populated at load time:
0:000> dx -r1 (*((x!Entry *)0x14007f000))
(*((x!Entry *)0x14007f000)) [Type: Entry]
[+0x000] a: 0 [Type: int]
[+0x004] b: 1 [Type: int]
[+0x008] c: 2 [Type: int]
[+0x00c] d: 3 [Type: int]
So the initializer only needs to do:
0001`40006bb0 488d0d49840700 lea rcx,[x!myentry (0001`4007f000)]
0001`40006bb7 48ff2562930700 jmp qword ptr [x!Log (0001`4007ff20)]
But on clang, the members are zero at process load:
> clang-cl -Z7 -O2 -c x.cpp
> lld-link -debug x.obj
0:000> dx -r1 (*((x!Entry *)0x14005eac0))
(*((x!Entry *)0x14005eac0)) [Type: Entry]
[+0x000] a: 0 [Type: int]
[+0x004] b: 0 [Type: int]
[+0x008] c: 0 [Type: int]
[+0x00c] d: 0 [Type: int]
And the initializer writes the data manually:
0001`40001014 0f2805e5bf0400 movaps xmm0,xmmword ptr [x!_xmm
(0001`4004d000)]
0001`4000101b 0f29059eda0500 movaps xmmword ptr [x!myentry
(0001`4005eac0)],xmm0
0001`40001022 488d0d97da0500 lea rcx,[x!myentry (0001`4005eac0)]
0001`40001029 ff1581da0500callqword ptr [x!Log (0001`4005eab0)]
--
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 37432] OUTPUT_FORMAT from linker script doesn't override the -m flag
https://bugs.llvm.org/show_bug.cgi?id=37432 Dmitry Golovin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Dmitry Golovin --- Oops, I spoke too soon. Turns out the bug is still there exactly as described in original report: -m option has higher priority than OUTPUT_FORMAT directive. -- 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 15880] Attempts to generate x86 rol instructions yield sub-optimal results
https://bugs.llvm.org/show_bug.cgi?id=15880 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Sanjay Patel --- Although this is the older bug and was more general, the underlying problem for the remaining part is already better described in bug 32023, so I'm going to mark this as a duplicate of that one. *** This bug has been marked as a duplicate of bug 32023 *** -- 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 35842] Clang 6 fails to compile boost variant code in unnamed namespace
https://bugs.llvm.org/show_bug.cgi?id=35842 Louis Dionne changed: What|Removed |Added Status|NEW |RESOLVED CC||ldio...@apple.com Resolution|--- |INVALID --- Comment #2 from Louis Dionne --- The problem is that Boost.Variant incorrectly uses `boost::declval` in an evaluated context. The compiler correctly diagnoses the invalid usage. Basically, boost::declval is a never-defined function template. It is instantiated in a TU with a type that has internal linkage (i.e. defined in an anonymous namespace), and so the compiler can tell no definition of boost::declval can ever exist. -- 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 39682] New: frewrite-imports not usable with umbrella directory declarations
https://bugs.llvm.org/show_bug.cgi?id=39682
Bug ID: 39682
Summary: frewrite-imports not usable with umbrella directory
declarations
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Modules
Assignee: unassignedclangb...@nondot.org
Reporter: dblai...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
foo.h:
// empty
use.cpp:
#include "foo.h"
// empty
module.modulemap:
module A {
umbrella "."
module * { export * }
}
$ clang++ -fmodules -c -xc++ -Xclang -emit-module -fmodule-name=A
module.modulemap -o A.pcm
$ clang++ -fmodules -fmodule-file=A.pcm use.cpp -frewrite-imports -E -o x.cpp
$ clang++-tot -fmodules x.cpp
:1:30: error: submodule A.'foo' not declared in module map
#pragma clang module begin A.foo
^
While building module 'A' imported from x.cpp:1:
In file included from :2:
././foo.h:1:22: error: no matching '#pragma clang module begin' for this
'#pragma clang module end'
#pragma clang module end /*A.foo*/
^
use.cpp:1:29: fatal error: module 'A' not found
#pragma clang module import A.foo /* clang -frewrite-includes: implicit import
*/
~~~^
3 errors generated.
Richard mentioned that the expectation is that the modulemap written to the
rewrite-imports output file should contain the "module * { export * }" expanded
across the files, so it no longer contains the * globs.
For example, if the x.cpp is manually modified, replacing "module * { export *
}" with "module foo { export foo }" this does produce a file that
parses/compiles without error.
--
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 39683] New: clang silently ignores trivial_abi in some cases
https://bugs.llvm.org/show_bug.cgi?id=39683
Bug ID: 39683
Summary: clang silently ignores trivial_abi in some cases
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: com...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Target: x86_64-apple-darwin18.2.0
In the following code, the class Test is marked trivial_abi (and is not a
template class), and Clang does not produce any warnings about trivial_abi when
compiling it, yet for the function test() returning a value of that class,
Clang's generated code returns it through memory rather than a register.
I'm not sure whether this class should actually be eligible for trivial_abi or
not, but if not, there definitely should be a warning.
If you change the definition by adding an additional non-template move
constructor, then trivial_abi starts being respected:
+Test(Test &&other) { x = other.x; }
Tested on latest trunk targeting macOS.
--
struct Test {
int x;
Test(int x) : x(x) {}
template
Test(T &&other) { x = other.x; }
Test(const Test &) = delete;
template
Test &operator=(T &&other) { x = other.x; }
Test &operator=(const Test &) = delete;
} __attribute__((trivial_abi));
Test test() {
return Test(42);
}
--
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 39684] New: abi-isel.ll is not testing linux-32-pic
https://bugs.llvm.org/show_bug.cgi?id=39684 Bug ID: 39684 Summary: abi-isel.ll is not testing linux-32-pic Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: s...@chromium.org CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com There is a typo on line 5: ; RUN: llc < %s -mcpu=generic -mtriple=i686-unknown-linux-gnu -relocation-model=static -code-model=small -pre-RA-sched=list-ilp | FileCheck %s -check-prefix=LINUX-32-PIC I beleive it should say `-relocation-model=pic`. I tried fixing and then running ./utils/update_llc_test_checks.py but that generated much bigger diff than I was expecting. -- 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 39685] New: Inserting an element to an undef vector
https://bugs.llvm.org/show_bug.cgi?id=39685
Bug ID: 39685
Summary: Inserting an element to an undef vector
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: ahee...@gmail.com
CC: llvm-bugs@lists.llvm.org
```
target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
target triple = "wasm32-unknown-unknown"
define <16 x i8> @test(i8 %x) {
%v = insertelement <16 x i8> undef, i8 %x, i32 0
ret <16 x i8> %v
}
```
If you compile the code above with the command
llc -asm-verbose=false -wasm-keep-registers -wasm-disable-explicit-locals
-mattr=+simd128,+sign-ext test.ll
The result will be like
```
splat_v16i8:
.parami32
.result v128
i8x16.splat $push0=, $0
i8x16.replace_lane $push1=, $pop0, 1, $0
i8x16.replace_lane $push2=, $pop1, 2, $0
i8x16.replace_lane $push3=, $pop2, 3, $0
i8x16.replace_lane $push4=, $pop3, 4, $0
i8x16.replace_lane $push5=, $pop4, 5, $0
i8x16.replace_lane $push6=, $pop5, 6, $0
i8x16.replace_lane $push7=, $pop6, 7, $0
i8x16.replace_lane $push8=, $pop7, 8, $0
i8x16.replace_lane $push9=, $pop8, 9, $0
i8x16.replace_lane $push10=, $pop9, 10, $0
i8x16.replace_lane $push11=, $pop10, 11, $0
i8x16.replace_lane $push12=, $pop11, 12, $0
i8x16.replace_lane $push13=, $pop12, 13, $0
i8x16.replace_lane $push14=, $pop13, 14, $0
i8x16.replace_lane $push15=, $pop14, 15, $0
end_function
```
What does wasm backend do for undef elements? Does it initialize them to zero?
But anyway here, doesn't the first instruction, splat, set all elements to the
value give by the argument? I'm not sure why all 'replace_lane's below try to
set each element one by one with the same value, which was supposed to be done
anyway by the first splat instruction.
--
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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39661, which changed state. Bug 39661 Summary: Merge r344516, r344591 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=39661 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 39661] Merge r344516, r344591 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39661 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|r344516 r344591 |r344516 r344591 r347024 ||r347028 --- Comment #1 from Tom Stellard --- Merged: r347024, r347028 -- 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 39686] New: Union with variant member with non-trivial default constructor but another variant member has a default member initializer with deleted default constructor
https://bugs.llvm.org/show_bug.cgi?id=39686
Bug ID: 39686
Summary: Union with variant member with non-trivial default
constructor but another variant member has a default
member initializer with deleted default constructor
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: yaghmour.sha...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Given the following code which is a more minimal example taken from this
Stackoveflow question https://stackoverflow.com/q/53310690/1708801
struct X {
X() {}//non-trivial default constructor
};
union U {
X x;
int i{}; //default member initializer
};
void foo() {
U u;
}
clang gives the following diagnostic https://godbolt.org/z/6oTJ01 :
call to implicitly-deleted default constructor of 'U'
U u;
^
note: default constructor of 'U' is implicitly deleted because variant field
'x' has a non-trivial default constructor
X x;
^
but [class.default.ctor]p2 http://eel.is/c++draft/class.default.ctor#2.1 says:
A defaulted default constructor for class X is defined as deleted if:
- X is a union that has a variant member with a non-trivial default
constructor and no variant member of X has a default member initializer,
U does have a member with a default member initializer so the default
constructor should not be deleted and this should be well-formed.
--
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
