[llvm-bugs] [Bug 44282] New: Diagnostic missing from -Wcast-qual in C++
https://bugs.llvm.org/show_bug.cgi?id=44282
Bug ID: 44282
Summary: Diagnostic missing from -Wcast-qual in C++
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: warren_ris...@playstation.sony.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The test-case below has two functions in it, both of which cast a const pointer
to a 'void *', dropping the const qualifier. I believe they both should
produce a warning when compiled with '-Wcast-qual'. The function 'foo()'
(which casts a 'const float *' to a 'void *') does not produce the warning,
whereas the function 'bar()' (which casts a 'const void *' to a 'void *') does.
Tested this with llvm 9.0.
$ cat test.cpp
extern void usePtr(const void *ptr);
void foo(const float *pf_const)
{
// Casting away const-ness, but no warning appears here.
usePtr((void *) pf_const);
}
void bar(const void *pv_const)
{
// Casting away const-ness, and warning does appear here.
usePtr((void *) pv_const);
}
$ clang++ -c -Wcast-qual test.cpp
test.cpp:13:19: warning: cast from 'const void *' to 'void *' drops const
qualifier [-Wcast-qual]
usePtr((void *) pv_const);
^
1 warning generated.
$
I noticed that an appropriate diagnostic does appear on both of these cases if
the test is compiled as C, rather than C++. So maybe there is some C++ subtlety
that means the 'foo()' example above should not get a warning. That said, GCC
produces the warning for both cases, in both C and C++ mode (tested GCC 7.4.0).
This looks to be similar to bug 23396, although not quite the same.
--
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 44281] New: clang frontend segfault when multiple make jobs running concurrently
https://bugs.llvm.org/show_bug.cgi?id=44281 Bug ID: 44281 Summary: clang frontend segfault when multiple make jobs running concurrently Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jeff.lina...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22933 --> https://bugs.llvm.org/attachment.cgi?id=22933=edit clang concurrent make segfault output I think clang-9 appears to be trying to execute a command called "Segmentation fault (core dumped)" but I don't see a core file anywhere (even with ulimit -c unlimited) Workaround is to just run make without -j so I think it has something to do with the frontend receiving some sort of signal when multiple processes are kicked off. I have no better idea what's going on without the core file so here's my source code and steps to reproduce: On Manjaro Linux 4.19.85 and clang 9.0.0: $ git clone https://github.com/jeffythedragonslayer/lipton-tarjan.git $ cd lipton-tarjan $ make -j 16 -- 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 44277] LLD segfaults when linking the Aarch64 Linux kernel with ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=44277 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@maskray.me Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- Our internal testing also noticed that this commit was causing problems. The author has reverted it in commit 56232f950d34b6c04a86ce916d456e599d77ec27, so closing. -- 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 44280] New: clang-cl silently ignores -Xclang -L and -Xclang -l
https://bugs.llvm.org/show_bug.cgi?id=44280 Bug ID: 44280 Summary: clang-cl silently ignores -Xclang -L and -Xclang -l Product: clang Version: 9.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: alexchan...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk (This is --target=i686-pc-windows-msvc,) invoking clang-cl with -Xclang -L does not result clang passing '-libpath:' to the linker. Similarly with -l. This is particularly painful when cross-compiling. -Xclang --sysroot= and -Xclang -isysroot appear similarly ignored. -- 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 44279] New: Opportunity for reusing jccs for long branches
https://bugs.llvm.org/show_bug.cgi?id=44279
Bug ID: 44279
Summary: Opportunity for reusing jccs for long branches
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Ran across an interesting opportunity for reducing code size of branch dense
code without negatively impacting performance. The basic notion is that if we
have a bunch of branches which share a branch target, we can use a short jump
to redirect to a single long jump. (i.e. it's a variation of branch islands)
(Reminder: short jumps are 2 bytes w/a byte offset, long jumps are 6 bytes w/a
4 byte offset)
Here's a little motivating IR fragment:
define void @test(i32 %a, i32 %b, i32 %c, i32 %d) {
%cmp1 = icmp slt i32 %a, %b
%cmp2 = icmp slt i32 %c, %d
%and = and i1 %cmp1, %cmp2
br i1 %and, label %taken, label %untaken, !prof !{!"branch_weights", i64
99, i64 0}
taken:
call void @foo()
ret void
... put code here to ensure this is far away ...
untaken:
call void @bar()
ret void
}
declare void @foo()
declare void @bar()
Our lowering for this today will end up looking like this:
1: 39 f7 cmpl%esi, %edi
3: 0f 8d b4 00 00 00 jge 180
9: 39 ca cmpl%ecx, %edx
b: 0f 8d ac 00 00 00 jge 172
That used two long jumps, and we got 16 bytes total for the branch dispatch
sequence.
Instead, we could have done:
0: 39 f7 cmpl%esi, %edi
2: 7d 02 jge 2
4: 39 ca cmpl%ecx, %edx
6: 0f 8d XX XX XX XX jge
This would have saved 4 bytes in this case.
This transform is code size neutral if the jumps turn out to be short jumps
after all, and performance neutral for the taken fallthrough path. (It does
slightly pessimise the untaken path.)
$ ../../build/bin/llc -O3 -mcpu=skylake < branch-island.ll |
../../build/bin/llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu - -o -
-mcpu=skylake | ../../build/bin/llvm-objdump -disassemble -
--
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 44278] New: Default --gc-sections breaks cmake test
https://bugs.llvm.org/show_bug.cgi?id=44278
Bug ID: 44278
Summary: Default --gc-sections breaks cmake test
Product: lld
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: wasm
Assignee: unassignedb...@nondot.org
Reporter: b...@pepin.io
CC: llvm-bugs@lists.llvm.org, s...@chromium.org
This could be addressed either on the lld or the cmake side, I'll let you
coordinate with the cmake maintainers if necessary.
The cmake CMAKE_SIZEOF_VOID_P macro compiles a temporary file with the size of
a pointer encoded in a string in one of the sections of the binary (see below).
It then tries to extract the result from the compiler output. However, with
--gc-sections enabled, the section containing the string in question is garbage
collected by the linker.
This breaks in particular the compilation of LLVM compiler-rt with wasm32 and
the default linker options.
To reproduce:
CMakeLists.txt:
message("CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P}")
toolchain.cmake:
set(CMAKE_SYSTEM_NAME WASM32)
set(CMAKE_SYSTEM_VERSION 1.0)
set(CMAKE_SYSTEM_PROCESSOR unknown)
set(triple wasm32)
set(CMAKE_C_COMPILER /usr/local/opt/llvm/bin/clang)
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER /usr/local/opt/llvm/bin/clang++)
set(CMAKE_CXX_COMPILER_TARGET ${triple})
# This gives CMAKE_SIZEOF_VOID_P 4
#set(CMAKE_EXE_LINKER_FLAGS_INIT "-nostdlib -Wl,--no-entry
-Wl,--no-gc-sections")
# This gives an empty CMAKE_SIZEOF_VOID_P
set(CMAKE_EXE_LINKER_FLAGS_INIT "-nostdlib -Wl,--no-entry")
The cmake code in question is at the top of
https://github.com/Kitware/CMake/blob/master/Modules/CMakeCompilerABI.h
/* Size of a pointer-to-data in bytes. */
#define SIZEOF_DPTR (sizeof(void*))
const char info_sizeof_dptr[] = {
/* clang-format off */
'I', 'N', 'F', 'O', ':', 's', 'i', 'z', 'e', 'o', 'f', '_', 'd', 'p', 't',
'r', '[', ('0' + ((SIZEOF_DPTR / 10) % 10)), ('0' + (SIZEOF_DPTR % 10)), ']',
'\0'
/* clang-format on */
};
--
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 44236] mergefunc makes function broken: Attribute 'byval' type does not match parameter
https://bugs.llvm.org/show_bug.cgi?id=44236 Nikita Popov changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||b361d3bbcd85647c9f6640a5f57 ||932c43fdb7a1a Resolution|--- |FIXED --- Comment #5 from Nikita Popov --- Fixed by https://github.com/llvm/llvm-project/commit/b361d3bbcd85647c9f6640a5f57932c43fdb7a1a. -- 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 44277] New: LLD segfaults when linking the Aarch64 Linux kernel with ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=44277
Bug ID: 44277
Summary: LLD segfaults when linking the Aarch64 Linux kernel
with ThinLTO
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: v...@apple.com
Reporter: samitolva...@google.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
ndesaulni...@google.com, r...@google.com,
tejohn...@google.com
Starting with commit 30038da15b18ac4e34b9ea7a648382ae481e4770 ("[DWARF] Allow
cross-CU references of subprogram definitions"), building the Linux kernel with
ThinLTO and LLD fails with a segmentation fault:
...
LTO vmlinux.o
Stack dump:
0. Running pass 'Function Pass Manager' on module
'arch/arm64/built-in.a(kernel/time.o at 4094)'.
1. Running pass 'AArch64 Assembly Printer' on function '@time_init'
LLVM ERROR: Failed to rename temporary file .thinlto-cache/Thin-d28bbb.tmp.o to
.thinlto-cache/llvmcache-C22016E1D1853F1DBC0C29919ED2F9B7CDF8E084: No such file
or directory
LLVM ERROR: Failed to rename temporary file .thinlto-cache/Thin-d9b995.tmp.o to
.thinlto-cache/llvmcache-BE7211A526D6D732AC88F1C1BCEC23592806F256: No such file
or directory
LLVM ERROR: Failed to rename temporary file .thinlto-cache/Thin-99c344.tmp.o to
.thinlto-cache/llvmcache-C7FECFD0C0C51CF353CF7961D21F44C1A8E02A6A: No such file
or directory
scripts/link-vmlinux.sh: line 71: 100211 Segmentation fault ${LD}
${KBUILD_LDFLAGS} -r -o ${1} $(lto_lds) ${objects}
make: *** [Makefile:1136: vmlinux] Error 139
Steps to reproduce:
$ git clone https://github.com/samitolvanen/linux.git
$ cd linux
$ git checkout clang-lto
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang LD=ld.lld
defconfig
$ ./scripts/config -e LTO_CLANG -e THINLTO
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang LD=ld.lld -j110
I've confirmed that reverting commit 30038da15b18ac4e34b9ea7a648382ae481e4770
fixes the issue.
Note that not passing --thinlto-cache-dir to LLD removes the "Failed to rename
temporary file" errors, but still results in a segfault.
--
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 42585] SROA assert fails VTy == CandidateTys[0] && "Different vector types with the same element type!
https://bugs.llvm.org/show_bug.cgi?id=42585 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r372480 |r372480 f2c8771 Status|REOPENED|RESOLVED --- Comment #6 from Tom Stellard --- Merged: f2c8771 -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 42585, which changed state. Bug 42585 Summary: SROA assert fails VTy == CandidateTys[0] && "Different vector types with the same element type! https://bugs.llvm.org/show_bug.cgi?id=42585 What|Removed |Added Status|REOPENED|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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 43397, which changed state. Bug 43397 Summary: Merge r371557 into 9.0.1 https://bugs.llvm.org/show_bug.cgi?id=43397 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 43397] Merge r371557 into 9.0.1
https://bugs.llvm.org/show_bug.cgi?id=43397 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|r371557 |r371557 e8e0c07 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tom Stellard --- Merged: e8e0c07 -- 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 44273] Why is there a difference between void and int ?
https://bugs.llvm.org/show_bug.cgi?id=44273 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- NISLParameter0 is uninitialised; it's not reasonable to expect it to have any particular value. -- 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 44276] New: [PowerPC] vec_splats cannot be used to initialize variables with static storage duration
https://bugs.llvm.org/show_bug.cgi?id=44276
Bug ID: 44276
Summary: [PowerPC] vec_splats cannot be used to initialize
variables with static storage duration
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Headers
Assignee: unassignedclangb...@nondot.org
Reporter: colin.samp...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
nemanja.i@gmail.com, richard-l...@metafoo.co.uk
Compiling the following C code:
#include
static vector int a = vec_splats(1);
int main() { return 0; }
results in:
test2.c:2:23: error: initializer element is not a compile-time constant
static vector int a = vec_splats(1);
This compiles on GCC and when compiled as C++ (although not in a C++ constexpr
context).
The definition of vec_splats from altivec.h is:
static __inline__ vector int __ATTRS_o_ai vec_splats(int __a) {
return (vector int)(__a);
}
By manually inlining it, the program compiles:
#include
static vector int a = (vector int)(1);
int main() { return 0; }
vec_promote is similar in that it GCC allows it to be used to initialize a
variable with static storage duration; however, the present implementation in
LLVM does not allow static initialization even when manually inlined.
I guess the issue here is use of functions rather than macros, but using macros
would run into the same issue as bug #44241; is there some better way to do
this?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 17483 in oss-fuzz: llvm:clang-fuzzer: Timeout in clang-fuzzer
Updates: Labels: Deadline-Approaching Comment #3 on issue 17483 by sheriff...@chromium.org: llvm:clang-fuzzer: Timeout in clang-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17483#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 17498 in oss-fuzz: llvm:clang-fuzzer: ASSERT: DD && "queried property of class with no definition"
Updates: Labels: Deadline-Approaching Comment #2 on issue 17498 by sheriff...@chromium.org: llvm:clang-fuzzer: ASSERT: DD && "queried property of class with no definition" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17498#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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 17443 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Out-of-memory in llvm-dwarfdump-fuzzer
Updates: Labels: Deadline-Approaching Comment #2 on issue 17443 by sheriff...@chromium.org: llvm:llvm-dwarfdump-fuzzer: Out-of-memory in llvm-dwarfdump-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17443#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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 17329 in oss-fuzz: llvm:clang-format-fuzzer: ASSERT: PPBranchLevel >= 0 && PPBranchLevel <= (int)PPLevelBranchIndex.size()
Updates: Labels: Deadline-Approaching Comment #2 on issue 17329 by sheriff...@chromium.org: llvm:clang-format-fuzzer: ASSERT: PPBranchLevel >= 0 && PPBranchLevel <= (int)PPLevelBranchIndex.size() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17329#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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 17332 in oss-fuzz: llvm:clang-format-fuzzer: ASSERT: NewRemainingTokenColumns < RemainingTokenColumns
Updates: Labels: Deadline-Approaching Comment #2 on issue 17332 by sheriff...@chromium.org: llvm:clang-format-fuzzer: ASSERT: NewRemainingTokenColumns < RemainingTokenColumns https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17332#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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43013] std::reduce(begin, end, init) does not accept init with only move constructor
https://bugs.llvm.org/show_bug.cgi?id=43013 Kamlesh Kumar changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Kamlesh Kumar --- It's not a bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44071] "thunk creation not converged" error
https://bugs.llvm.org/show_bug.cgi?id=44071 Peter Smith changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #11 from Peter Smith --- Committed 247b2ce11cf0b9efeb3c1b0394dcc87ccab7be41 (D71242)and 86d24193a9eb45d7bf3745fc2de96cd4e197b08a (D71281) Marking as resolved for now. We can reopen if there are any problems. -- 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 44275] New: Assertion `cast(Expr)->isValid() && "not an expression"' for entry value for indirect parameter
https://bugs.llvm.org/show_bug.cgi?id=44275
Bug ID: 44275
Summary: Assertion `cast(Expr)->isValid() && "not
an expression"' for entry value for indirect parameter
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Reproduced on trunk (987e7323fb53f968d5878483610fcf2319cdde86).
When compiling the following file:
struct a {
a(a &) {}
};
class b {
a c;
};
class C {
protected:
C(int, int, b);
};
class d : C {
d(int &, b);
};
int e;
d::d(int , b g) : C(f, e, g) {}
using:
$ clang++ -Xclang -femit-debug-entry-values foo.cpp -O2 -g -c
an assertion fails:
clang-10: /path/to/monorepo/llvm/lib/CodeGen/MachineInstr.cpp:2019:
llvm::MachineInstrBuilder llvm::BuildMI(llvm::MachineFunction&, const
llvm::DebugLoc&, const llvm::MCInstrDesc&, bool, llvm::Register, const
llvm::MDNode*, const llvm::MDNode*): Assertion
`cast(Expr)->isValid() && "not an expression"' failed.
Stack dump:
0. Program arguments: /path/to/monorepo/build/bin/clang-10 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name foo.cpp
-mrelocation-model static -mthread-model posix -mframe-pointer=none
-fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-fno-split-dwarf-inlining -debug-info-kind=limited -dwarf-version=4
-debugger-tuning=gdb -resource-dir /path/to/monorepo/build/lib/clang/10.0.0
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/backward
-internal-isystem /usr/local/include -internal-isystem
/path/to/monorepo/build/lib/clang/10.0.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O2 -fdeprecated-macro
-fdebug-compilation-dir /path/to/monorepo -ferror-limit 19 -fmessage-length 0
-fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-femit-debug-entry-values -faddrsig -o foo.o -x c++ foo.cpp
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'foo.cpp'.
4. Running pass 'Live DEBUG_VALUE analysis' on function '@_ZN1dC2ERi1b'
This happens we are creating an entry value for:
DBG_VALUE $rdx, $noreg, !"g", !DIExpression(DW_OP_deref), debug-location
!42; foo.cpp:15:16 line no:15
Currently DIExpression::isValid() assumes the following for entry values:
return I->get() == expr_op_begin()->get() && I->getArg(0) == 1 &&
getNumElements() == 2;
It is the (getNumElements() == 2) check which causes the verifier to fail, due
to presence of the DW_OP_deref. That check is there since we're missing things
in DwarfExpression, and perhaps other places, to correctly emit entry values in
those cases.
This is what GCC emits for this case:
0028 000a (DW_OP_breg1 (rdx): 0)
002e 000a 0040 (DW_OP_entry_value: (DW_OP_reg1
(rdx)))
This happens often for C++ programs, so if we are not able to fix this quickly
I think we should change LiveDebugValues so that we don't run into this issue.
--
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 44274] New: Unknown standard opcodes printed as (null) in prologue
https://bugs.llvm.org/show_bug.cgi?id=44274 Bug ID: 44274 Summary: Unknown standard opcodes printed as (null) in prologue Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com If the opcode base of a line table prologue is higher than 13 (i.e. the program defines unknown standard opcodes), the unknown opcodes are printed as "(null)" in the array, which doesn't look great. We should probably print something like "DW_LNS_unknown" instead, which roughly matches what is done for unknown DW_AT_* and other DWARF constants. See test/tools/llvm-dwarfdump/X86/debug-line.s for an example: # CHECK-NEXT: opcode_base: 14 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_copy] = 0 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_advance_pc] = 1 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_advance_line] = 1 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_set_file] = 1 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_set_column] = 1 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_negate_stmt] = 0 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_set_basic_block] = 0 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_const_add_pc] = 0 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_fixed_advance_pc] = 1 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_set_prologue_end] = 0 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_set_epilogue_begin] = 0 # CHECK-NEXT: standard_opcode_lengths[DW_LNS_set_isa] = 1 # CHECK-NEXT: standard_opcode_lengths[(null)] = 0 *** BAD *** The verbose dumping currently prints these as an empty string, probably for the same reason at a guess. -- 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 44273] New: Why is there a difference between void and int ?
https://bugs.llvm.org/show_bug.cgi?id=44273
Bug ID: 44273
Summary: Why is there a difference between void and int ?
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: 1059252...@qq.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Hi, when define a pointer NISLParameter0 without assigning it a value, Clang
will behave inconsistently depending on the return value of the main function.
When main function’s return type is “void”, clang will not allocate an address
for it. But if main function’s return type is “int”, clang will allocate an
address successfully.Although void main is not recommended by ISO C standard,
they should also be consistent.
TestCase:
#include
#include
void function(void *d)
{
if (d == NULL)
printf("%d\n",111);
}
int main()
{
int *NISLParameter0;
function(NISLParameter0);
return 0;
}
Command:
./clang/version9.0/bin/clang testcase.c
Output:
111 (main function’s return type is void)
(no output when main function’s return type is int)
Expected output:
The same between void and int return types.
Is this right for clang? Looking forward to your reply.
--
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 28122] clang crashes on C++ code with invalid assignment to complex number: Assertion `getValueKind() == VK_LValue' failed
https://bugs.llvm.org/show_bug.cgi?id=28122 Alexander Kornienko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ale...@google.com --- Comment #1 from Alexander Kornienko --- Looks very similar to http://llvm.org/PR27144 *** This bug has been marked as a duplicate of bug 27144 *** -- 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 13279] Assertion triggered in clang::Expr::ClassifyImpl
https://bugs.llvm.org/show_bug.cgi?id=13279 Alexander Kornienko changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||ale...@google.com --- Comment #1 from Alexander Kornienko --- Can't reproduce as of https://github.com/llvm/llvm-project/commit/3bf8558fbb2f3e9348bf1f5aafb64d8095ad6420 -- 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 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
https://bugs.llvm.org/show_bug.cgi?id=38768 Bug 38768 depends on bug 38754, which changed state. Bug 38754 Summary: [DebugInfo@O2][Dexter] Illegal value appears in variable when conditional blocks folded https://bugs.llvm.org/show_bug.cgi?id=38754 What|Removed |Added Status|CONFIRMED |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 38754] [DebugInfo@O2][Dexter] Illegal value appears in variable when conditional blocks folded
https://bugs.llvm.org/show_bug.cgi?id=38754 Jeremy Morse changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||00e238896c --- Comment #14 from Jeremy Morse --- placeDbgValues was significantly limited in 00e238896c, and it looks like the patch is sticking. There's still some work to be done with debug use-before-defs (which are already an error-state), but the vast majority of faulty behaviour should now be fixed. Horray! (I'll clean up the other tickets this depends on, which fall into the category of "things that Jeremy saw and bothered him", at some other time). -- 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 38754] [DebugInfo@O2][Dexter] Illegal value appears in variable when conditional blocks folded
https://bugs.llvm.org/show_bug.cgi?id=38754 Bug 38754 depends on bug 39940, which changed state. Bug 39940 Summary: [DebugInfo@O2] CodeGenPrepare address-mode sinking limits dbg.value validity https://bugs.llvm.org/show_bug.cgi?id=39940 What|Removed |Added Status|CONFIRMED |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 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
https://bugs.llvm.org/show_bug.cgi?id=38768 Bug 38768 depends on bug 39940, which changed state. Bug 39940 Summary: [DebugInfo@O2] CodeGenPrepare address-mode sinking limits dbg.value validity https://bugs.llvm.org/show_bug.cgi?id=39940 What|Removed |Added Status|CONFIRMED |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 39940] [DebugInfo@O2] CodeGenPrepare address-mode sinking limits dbg.value validity
https://bugs.llvm.org/show_bug.cgi?id=39940 Jeremy Morse changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||c93a9b15ce88 --- Comment #2 from Jeremy Morse --- Fixed in rGc93a9b15ce88 -- 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 38754] [DebugInfo@O2][Dexter] Illegal value appears in variable when conditional blocks folded
https://bugs.llvm.org/show_bug.cgi?id=38754 Bug 38754 depends on bug 31878, which changed state. Bug 31878 Summary: CodeGenPrepare::placeDbgValues moves llvm.dbg.value without proper analysis https://bugs.llvm.org/show_bug.cgi?id=31878 What|Removed |Added Status|CONFIRMED |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 31878] CodeGenPrepare::placeDbgValues moves llvm.dbg.value without proper analysis
https://bugs.llvm.org/show_bug.cgi?id=31878 Jeremy Morse changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||00e238896c Resolution|--- |FIXED --- Comment #9 from Jeremy Morse --- placeDbgValues was significantly limited in 00e238896c, and it looks like the patch is sticking. There's still some work to be done with debug use-before-defs (which are already an error-state), but the vast majority of faulty behaviour should now be 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 44272] New: [CLANG-CL] 64x inline assembler function call/jump miscompiled
https://bugs.llvm.org/show_bug.cgi?id=44272
Bug ID: 44272
Summary: [CLANG-CL] 64x inline assembler function call/jump
miscompiled
Product: new-bugs
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: zegzmanz...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
I've recently starting using Clang-CL in Visual Studio 2019 and I've discovered
a fatal bug within the compiler, when attempting to call a function within
inline assembly the function pointer is dereferenced, causing to crash due to
memory access violation, the same issue exists by attempting to "jmp" to a
function directly, I've tried to fix this in various ways, but I only found a
way to get around the problem, this happens only with 64bit inline assembler
and the fatal bug is clearly visible within assembly output.
The problem is replicated by doing something like this:
int main() {
__asm {
xor rcx, rcx
call exit
}
printf("The application didn't quit!");
return 0;
}
The generated inline assembly looks like this:
xor rcx, rcx
call qword ptr [exit]
The way I get around the problem is by using "lea" instruction to retrieve the
function pointer, which looks like this:
__asm {
xor rcx, rcx
lea rax, exit
call rax
}
Results in generated inline assembly that looks like this:
xor rcx, rcx
lea rax, [exit]
call rax
This no longer results in a crash.
My Clang-CL installation (--version):
CLang Version: 9.0.0 (release-final)
Target: x86_64-pc-windows-msvc
InstalledDir: C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\Llvm\bin
The Clang-CL compiler is downloaded via visual studio 2019 installer, selecting
the "C++ Clang tools for Windows (9.0.0 - x64/x86)"
I hope this problem can be addressed soon, this is my first time reporting a
bug. Thank you.
--
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 44271] New: Assertion failure (Windows on Arm): assert((!RPI.isPaired() || !NeedsFrameRecord || RPI.Reg2 != AArch64::FP || RPI.Reg1 == AArch64::LR) && "FrameRecord mst be allocated to
https://bugs.llvm.org/show_bug.cgi?id=44271 Bug ID: 44271 Summary: Assertion failure (Windows on Arm): assert((!RPI.isPaired() || !NeedsFrameRecord || RPI.Reg2 != AArch64::FP || RPI.Reg1 == AArch64::LR) && "FrameRecord mst be allocated together with LR") Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: richard.towns...@arm.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22932 --> https://bugs.llvm.org/attachment.cgi?id=22932=edit Reproducer When running the attached reproducer with this command line: "clang-cl" "-cc1" "-triple" "arm64-unknown-windows-msvc19.16.0" "-emit-obj" "-mframe-pointer=all" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "--show-includes" "-fno-rtti-data" "-stack-protector" "2" "-nostdsysteminc" "-D" "UCHAR_TYPE=wchar_t" "-D" "__DATE__=" "-D" "__TIME__=" "-D" "__TIMESTAMP__=" "-Os" "-Wno-builtin-macro-redefined" "-fms-extensions" "-std=c++14" "-x" "c++" "reduce.cpp" We get an assertion failure in computeCalleeSaveRegisterPairs (AArch64FrameLowering.cpp). This reproducer is based on a region of the Chromium code base (lzma_util.cc). The issue appears to come from the fact that the compiler's trying pair X19 with X29/FP, which doesn't meet the assertion's conditions. -- 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
