[llvm-bugs] [Bug 81723] #77856 causes a minor performance regression in stage2 clang builds
Issue 81723 Summary #77856 causes a minor performance regression in stage2 clang builds Labels Assignees Reporter DianQK FWIW, it seems like this causes a minor performance regression in stage2 clang builds (https://llvm-compile-time-tracker.com/compare.php?from=5aec9392674572fa5a06283173a6a739742d261d&to=5932fcc47855fdd209784f38820422d2369b84b2&stat=instructions:u). Though code size does reduce as well. _Originally posted by @nikic in https://github.com/llvm/llvm-project/issues/77856#issuecomment-1937851382_ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81728] llvm-17: huge compile time and ll-file size
Issue 81728 Summary llvm-17: huge compile time and ll-file size Labels new issue Assignees Reporter sidtvera [quark.17.x64.ii.gz](https://github.com/llvm/llvm-project/files/14279009/quark.17.x64.ii.gz) ``` $ time clang-17 -x c -w -O1 quark.17.x64.ii -S -emit-llvm -o quark.17.x64.O1.ll user 1m21,823s $ time clang-17 -x c -w -O0 quark.17.x64.ii -S -emit-llvm -o quark.17.x64.O0.ll user 0m0,087s $ time clang-14 -x c -w -O1 quark.17.x64.ii -S -emit-llvm -o quark.14.x64.O1.ll user 0m1,404s $ ls -lh 175K quark.17.x64.ii 2,1M quark.14.x64.O1.ll 474K quark.17.x64.O0.ll 56M quark.17.x64.O1.ll ``` While clang-14 produces ll-file with size 2M, clang-17 produces ll-file with size 56M (25 times more) and a compile time is increased a very much. At first sight, some optimization increases a number of edges in control flow graph and makes very many value sources for phi-nodes. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81731] Clang c++ compiles error with struct in template class and < operator
Issue
81731
Summary
Clang c++ compiles error with struct in template class and < operator
Labels
clang
Assignees
Reporter
wangbo15
Please consider the following code:
```c++
template
class confused{};
template
class test
{
void foo() {
if(this->b.confused < 1);
};
struct bar
{
int confused;
} b;
};
```
Clang rejects it by giving such considerably puzzling output:
```c++
:8:32: error: expected '>'
8 | if(this->b.confused < 1);
| ^
:8:29: note: to match this '<'
8 | if(this->b.confused < 1);
| ^
:8:32: error: expected unqualified-id
8 | if(this->b.confused < 1);
| ^
:8:33: warning: if statement has empty body [-Wempty-body]
8 | if(this->b.confused < 1);
| ^
:8:33: note: put the semicolon on a separate line to silence this warning
1 warning and 2 errors generated.
Compiler returned: 1
```
We suppose that's because the compiler has found incorrect local variable name of `confused` by confusing the global template class declared above with the integer member variable declared in the nested class `bar` inside `test`
Please check [https://godbolt.org/z/7afqsvEvo](https://godbolt.org/z/7afqsvEvo).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81733] Clang behaves somewhat weirdly with pointer to member field cast inside a class not completed and inheritance
Issue
81733
Summary
Clang behaves somewhat weirdly with pointer to member field cast inside a class not completed and inheritance
Labels
clang
Assignees
Reporter
Rush10233
The following code compiles normally in clang:
```c++
struct A { int i; };
struct B:A { int j; };
struct C:B { int k; static_assert((int(B::*))&C::k, ""); };
```
But it's rejected by gcc which complains that `&C::k` should not be constant before the class `C` is completed:
```c++
:3:35: error: non-constant condition for static assertion
3 | struct C:B { int k; static_assert((int(B::*))&C::k, ""); };
| ^~~~
:3:35: error: '&C::k' is not a constant _expression_ when the class 'C' is still incomplete
Compiler returned: 1
```
Note that the `static_assert` _expression_ requires its first parameter to be compile-time constant. It seems at least one of the compilers does the wrong thing. Since the standard of class member variable pointer assignment looks a little complex, we currently cannot judge for certain which behavior is reasonable. We hope that can be further identified.
[https://godbolt.org/z/MWeYx7sYq](https://godbolt.org/z/MWeYx7sYq)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81734] [clang] False positive clang-analyzer-core.DivideZero with loop over container
Issue
81734
Summary
[clang] False positive clang-analyzer-core.DivideZero with loop over container
Labels
clang
Assignees
Reporter
chrchr-github
~~~c++
#include
int f(const std::vector& v) {
if (v.empty())
return 0;
int h = 0;
for (auto it = v.begin(); it != v.end(); ++it) {
h = std::max(h, *it);
}
int x = 512;
if (h < x)
h = h * (x / h + 1);
return h;
}
~~~
~~~
:12:20: warning: Division by zero [clang-analyzer-core.DivideZero]
12 | h = h * (x / h + 1);
| ~~^~~
:3:9: note: Assuming the condition is false]
3 | if (v.empty())
| ^
:3:5: note: Taking false branch]
3 | if (v.empty())
| ^
:5:5: note: 'h' initialized to 0
5 | int h = 0;
| ^
:6:5: note: Loop condition is false. Execution continues on line 10
6 | for (auto it = v.begin(); it != v.end(); ++it) {
| ^
:11:9: note: 'h' is < 'x'
11 | if (h < x)
| ^
:11:5: note: Taking true branch
11 | if (h < x)
| ^
:12:20: note: Division by zero
12 | h = h * (x / h + 1);
| ~~^~~
~~~
There could be division by zero if the vector holds only numbers <= 0. However, the diagnostic seems to imply that the vector might be empty, which is impossible.
https://godbolt.org/z/cbKh7axxd
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81740] [lld/ELF] LLD does not set ELFOSABI_GNU when using IFUNC
Issue 81740 Summary [lld/ELF] LLD does not set ELFOSABI_GNU when using IFUNC Labels lld Assignees Reporter uweigand When creating a binary using IFUNC symbols with LLD, (GNU) readelf does not show the type correctly. We see ``` 692: 00122de028 : 10 GLOBAL DEFAULT 18 strstr@@GLIBC_2.2 ``` instead of ``` 692: 00122de028 IFUNC GLOBAL DEFAULT 18 strstr@@GLIBC_2.2 ``` It turns out that this is because GNU readelf thinks symbol type 10 means IFUNC only on GNU / Linux and FreeBSD targets (and indeed 10 is in the "OS specific" range of symbol types according to the ELF definition): ``` if (type == STT_GNU_IFUNC && (filedata->file_header.e_ident[EI_OSABI] == ELFOSABI_GNU || filedata->file_header.e_ident[EI_OSABI] == ELFOSABI_FREEBSD)) return "IFUNC"; ``` The GNU linker has code that will set the OSABI field to ELFOSABI_GNU if the output binary contains any IFUNC symbols. LLD does not currently appear to do so. Should it? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81742] Merge ac97562c99c3ae97f063048ccaf08ebdae60ac30 into 18.x
Issue 81742 Summary Merge ac97562c99c3ae97f063048ccaf08ebdae60ac30 into 18.x Labels new issue Assignees Reporter brad0 [OpenMP][AIX]Define struct kmp_base_tas_lock with the order of two members swapped for big-endian (#79188) The direct lock data structure has bit `0` (the least significant bit) of the first 32-bit word set to `1` to indicate it is a direct lock. On the other hand, the first word (in 32-bit mode) or first two words (in 64-bit mode) of an indirect lock are the address of the entry allocated from the indirect lock table. The runtime checks bit `0` of the first 32-bit word to tell if this is a direct or an indirect lock. This works fine for 32-bit and 64-bit little-endian because its memory layout of a 64-bit address is (`low word`, `high word`). However, this causes problems for big-endian where the memory layout of a 64-bit address is (`high word`, `low word`). If an address of the indirect lock table entry is something like `0x110035300`, i.e., (`0x1`, `0x10035300`), it is treated as a direct lock. This patch defines `struct kmp_base_tas_lock` with the ordering of the two 32-bit members flipped for big-endian PPC64 so that when checking/setting tags in member `poll`, the second word (the low word) is used. This patch also changes places where `poll` is not already explicitly specified for checking/setting tags. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81745] undefined reference to consteval constructor exported from module
Issue
81745
Summary
undefined reference to consteval constructor exported from module
Labels
new issue
Assignees
Reporter
stbergmann
At least with Clang 17.0.6:
```
$ cat test.cppm
export module M;
export struct S1 { consteval S1(int) {} };
```
```
$ clang++ -std=c++20 test.cppm --precompile
```
```
$ cat test-main.cc
import M;
int main() {
struct S2 { S1 s = 0; };
S2 s;
}
```
```
$ clang++ -std=c++20 test-main.cc -fmodule-file=M=test.pcm test.pcm
/usr/bin/ld: /tmp/test-main-f78021.o: in function `main::S2::S2()':
test-main.cc:(.text+0x33): undefined reference to `S1@M::S1(int)'
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81752] [DirectX][DXIL] Enhance DXIL.td to be serve as the single source of reference for DXIL Operations
Issue 81752 Summary [DirectX][DXIL] Enhance DXIL.td to be serve as the single source of reference for DXIL Operations Labels new issue Assignees Reporter bharadwajy DXIL.td should be single source of reference for all DXIL operations. It should be subsume all relevant and applicable functionalities of [`hctdb.py`](https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/hct/hctdb.py) and other `hct` utilities. Currently the `DXILEmitter` backend generates code used for lowering LLVM IR intrinsics to DXIL Ops. Another utility of the `DXIL.td` could be in the [upgrade pass](https://github.com/llvm/llvm-project/blob/main/llvm/docs/DirectX/DXILArchitecture.rst#the-dxilupgrade-pass) with an appropriate backend (or even reusing `DXILEmitter` backend. Some of the top-level sub-tasks are 1. Refine existing abstractions in DXIL to model DXIL operation characteristics such as instruction categories, types supported, parameter formats etc. 2. Currently only a small number (6) of DXIL operations are specified. The remaining ones, along with tests to verify DXIL lowering, need to added. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81753] [SPIRV] OpExecutionMode Entry Point is not the Entry Point operand of an OpEntryPoint
Issue
81753
Summary
[SPIRV] OpExecutionMode Entry Point is not the Entry Point operand of an OpEntryPoint
Labels
new issue
Assignees
Reporter
VyacheslavLevytskyy
SPIRV-V Backend generates unnecessary OpExecutionMode records, putting into the 's which are not the Entry Point operands of an OpEntryPoint and thus violating specification requirements (https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpExecutionMode).
Example of the code that causes one more, unnecessary OpExecutionMode record in addition to a required one is the following:
```
@GV = linkonce_odr addrspace(1) global [3 x i32] zeroinitializer, align 4
define spir_kernel void @k() {
entry:
%call = call spir_func i32 @square(i32 2)
ret void
}
define linkonce_odr dso_local spir_func i32 @square(i32 %in) {
entry:
%in.addr = alloca i32, align 4
store i32 %in, i32* %in.addr, align 4
%0 = load i32, i32* %in.addr, align 4
%1 = load i32, i32* %in.addr, align 4
%mul = mul nsw i32 %0, %1
ret i32 %mul
}
```
In the output there will be two OpExecutionMode instructions with just one OpEntryPoint:
```
...
OpEntryPoint Kernel %14 "k" %12
OpExecutionMode %14 ContractionOff
OpExecutionMode %17 ContractionOff
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81755] [X86] Use __builtin_readsteadycounter to access MPERF counter (and APERF equivalent(
Issue 81755 Summary [X86] Use __builtin_readsteadycounter to access MPERF counter (and APERF equivalent( Labels backend:X86 Assignees Reporter RKSimon #81331 added support for a `__builtin_readsteadycounter` intrinsic which returns a fixed frequency clock counter. It returns 0 on failure. x86 can use this as a wrapper to read the MPERF counter - on Intel (and default) I think this will need to lower to a libcall, but on AMD znver2 (or later) we can use the RDPRU instruction. Ideally we need a companion `__builtin_readvariablecounter` intrinsic which returns the APERF counter to calculate the effective cpu frequency (we can't use `__builtin_readcyclecounter` as that returns RDTSC which is a different time scale). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81765] [X86] Improve KnownBits for X86ISD::PSADBW nodes
Issue
81765
Summary
[X86] Improve KnownBits for X86ISD::PSADBW nodes
Labels
backend:X86
Assignees
Reporter
RKSimon
X86TargetLowering::computeKnownBitsForTargetNode currently just sets the upper 48-bits to be zero and makes no attempt to determine the remaining active bits.
```cpp
typedef uint8_t __v2qu __attribute__((__vector_size__(2)));
auto sum_of_bits(__m128i x) {
x = _mm_and_si128(x, _mm_set1_epi8(1));
x = _mm_sad_epu8(x, _mm_setzero_si128());
return __builtin_convertvector(x, __v2qu);
}
```
https://godbolt.org/z/74bYbTMh8
```asm
sum_of_bits(long long vector[2]): # @sum_of_bits(long long vector[2])
pand.LCPI0_0(%rip), %xmm0# v16i8 values: 0-1
pxor %xmm1, %xmm1
psadbw %xmm0, %xmm1 # v2i64 values: 0-8
pand.LCPI0_1(%rip), %xmm1# unneccessary
packuswb%xmm1, %xmm1
packuswb%xmm1, %xmm1
packuswb%xmm1, %xmm1
movd%xmm1, %eax
retq
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81766] llvm/lib/Target/AMDGPU/SIISelLowering.cpp: 2 * suspicious if statements
Issue
81766
Summary
llvm/lib/Target/AMDGPU/SIISelLowering.cpp: 2 * suspicious if statements
Labels
new issue
Assignees
Reporter
dcb314
Static analyser cppcheck says
1.
llvm/lib/Target/AMDGPU/SIISelLowering.cpp:14576:46: style: Same _expression_ on both sides of '||'. [duplicateExpression]
Source code is
// v2i16 (scalar_to_vector i16:x) -> v2i16 (bitcast (any_extend i16:x))
if (VT == MVT::v2i16 || VT == MVT::v2f16 || VT == MVT::v2f16) {
2.
llvm/lib/Target/AMDGPU/SIISelLowering.cpp:6308:65: style: Same _expression_ on both sides of '||'. [duplicateExpression]
Source code is
if (VT == MVT::v4f16 || VT == MVT::v8f16 || VT == MVT::v16f16 ||
VT == MVT::v16f16)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81767] Diagnose GNU-style attribute differences with GCC
Issue
81767
Summary
Diagnose GNU-style attribute differences with GCC
Labels
enhancement,
quality-of-implementation,
clang:diagnostics,
extension:gnu
Assignees
Reporter
AaronBallman
GCC was the initial implementer of the `__attribute__(())` extension, which Clang has copied. However, over the years, Clang has diverged from GCC in terms of where we accept the attribute syntactically (we've also diverged in terms of specific attribute implementations, but this issue is specific to the syntax of `__attribute__`). It would be nice to issue a diagnostic telling users about those divergences, under the `-Wgcc-compat` warning (or a new warning grouped under that one).
e.g.,
```
[[]] __attribute__(()) void func1(); // Both accept
__attribute__(()) [[]] void func2(); // Clang accepts, GCC rejects
struct [[]] __attribute__(()) S1 { // Both accept
};
struct __attribute__(()) [[]] S2 { // Clang accepts, GCC rejects
};
```
https://godbolt.org/z/oq5T55jfE
(We should try to be exhaustive at finding all the places we've diverged, more may exist than what's listed here.)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81769] C++20 says that these are ambiguous, even though the second is reversed
Issue
81769
Summary
C++20 says that these are ambiguous, even though the second is reversed
Labels
new issue
Assignees
Reporter
lednakashim
I tried to build some code bases with gcc13 and `-Werror `but got hit by a bunch of
```
include/mlir/IR/TypeRange.h:207:19: error: C++20 says that these are ambiguous, even though the second is reversed: [-Werror]
> 207 | return lhs == rhs;
```
for example in
```
static bool isEqual(mlir::TypeRange lhs, mlir::TypeRange rhs) {
if (isEmptyKey(rhs))
return isEmptyKey(lhs);
if (isTombstoneKey(rhs))
return isTombstoneKey(lhs);
return lhs == rhs;
}
```
Some number of these can be traced to unbalanced or missing consts?
```
template
inline bool operator==(ArrayRef lhs, const ValueTypeRange &rhs) {
return lhs.size() == static_cast(llvm::size(rhs)) &&
std::equal(lhs.begin(), lhs.end(), rhs.begin());
}
```
Apparently you can't actually disable this error in gcc without knocking out almost all warnings
https://stackoverflow.com/questions/77992645/silence-ambiguous-reversed-operator-warning-in-gcc13?noredirect=1#comment137501323_77992645
Not really sure how llvm deals with this stuff.
Additionally does llvm build with gcc13?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81774] Clang incorrectly rejects default construction of union with nontrivial member, part 2
Issue
81774
Summary
Clang incorrectly rejects default construction of union with nontrivial member, part 2
Labels
clang
Assignees
Reporter
StephanTLavavej
Accepted by VS 2022 17.10 Preview 1, rejected by Clang 17.0.3.
On Compiler Explorer, accepted by GCC 13.2, rejected by Clang 17.0.1 and trunk: https://godbolt.org/z/8fGhWa1ss
Presumably related to #48416 which was previously reported and fixed, but this larger repro is still failing.
```
C:\Temp>type meow.cpp
```
```cpp
enum class BasicFormatArgType { NoType, CustomType };
struct Monostate {};
struct Handle {
Handle(int, int) {}
};
template
struct BasicFormatArg {
BasicFormatArg() = default;
BasicFormatArg(int x, int y) : ActiveState(BasicFormatArgType::CustomType), CustomState(x, y) {}
BasicFormatArgType ActiveState = BasicFormatArgType::NoType;
union {
Monostate NoState = Monostate{};
Handle CustomState;
};
};
int main() {
BasicFormatArg arg{};
(void) arg;
}
```
```
C:\Temp>cl /EHsc /nologo /W4 /std:c++latest /c meow.cpp
meow.cpp
C:\Temp>clang-cl -v
clang version 17.0.3
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin
C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest /c meow.cpp
meow.cpp(24,28): error: call to implicitly-deleted default constructor of 'BasicFormatArg'
24 | BasicFormatArg arg{};
| ^ ~~
meow.cpp(11,5): note: explicitly defaulted function was implicitly deleted here
11 | BasicFormatArg() = default;
| ^
meow.cpp(19,16): note: default constructor of 'BasicFormatArg' is implicitly deleted because field 'CustomState'
has no default constructor
19 | Handle CustomState;
| ^
1 error generated.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81779] [HLSL] Disallow 16-bit integer types if native 16-bit types are disabled
Issue 81779 Summary [HLSL] Disallow 16-bit integer types if native 16-bit types are disabled Labels new issue Assignees Reporter llvm-beanz DXC disallows declarations of 16-bit types if the native 16-bit types are disabled. In Clang, we `#ifdef` out the 16-bit intrinsics to prevent generating 16-bit types. ### Acceptance Criteria Test cases that produce diagnostics when users use 16-bit types without enabling native 16-bit types. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81786] [flang] function reference passed to extends_type_of intrinsic is not called
Issue 81786 Summary [flang] function reference passed to extends_type_of intrinsic is not called Labels bug, flang:frontend Assignees Reporter kkwli Reproducer ```fortran module m type Base integer i contains final :: finalizeBase end type type, extends(Base) :: Child contains final :: finalizeChild end type contains subroutine finalizeBase(b) type(Base), intent(inout) :: b print *, "finalizeBase" end subroutine subroutine finalizeChild(c) type(Child), intent(inout) :: c print *, "finalizeChild" end subroutine function func1() class(Base), allocatable :: func1 allocate(Base::func1) print*, 'func1 ...' end function end module program main use m type(Base) :: arg1 logical :: l l = extends_type_of(func1(), arg1) end ``` The expected output is `func1` is called as well as `finalizeBase` due to finalization of the function result. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81787] Request to build llvm-symbolizer in the official clang releases against zlib
Issue 81787 Summary Request to build llvm-symbolizer in the official clang releases against zlib Labels clang Assignees Reporter mknyszek Currently, the releases at https://releases.llvm.org/ for linux-amd64 (Ubuntu) aren't built against zlib. In the Go project's build infrastructure, we want to build against clang. We currently avoid baking clang into our CI Linux images via https://apt.llvm.org packages, because managing more images increases our maintenance overhead, and makes it harder for us to test against multiple versions of clang. Instead, we take the official LLVM releases and download them onto our CI jobs on-demand. Unfortunately, these releases don't build against zlib, so I've temporarily modified some of our ASAN tests against clang (specifically disabled just the parts that check for correct symbolization) because llvm-symbolizer fails to decompress a Go binary's DWARF info. (https://github.com/golang/go/issues/65606) This is basically a formal request made out of the discourse thread here, https://discourse.llvm.org/t/clang-14-warning-cannot-compress-debug-sections-zlib-not-installed-wdebug-compression-unavailable-while-using-address-sanitizer/62506/2, where it seemed like it might be reasonable from the LLVM project's perspective to require a zlib installation to use the official clang releases. I'm hoping that the LLVM project is willing to modify its release processes to include building llvm-symbolizer against zlib. Of course, if the resolution is that that isn't possible, or is sufficiently undesirable, we'll have to figure something else out. But so far this approach has worked nicely for us, with this being the only issue we ran into. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81792] [-Wunsafe-buffer-usage] Incorrect fixit for unsafe pointer initialized with nullptr
Issue
81792
Summary
[-Wunsafe-buffer-usage] Incorrect fixit for unsafe pointer initialized with nullptr
Labels
new issue
Assignees
jkorous-apple
Reporter
jkorous-apple
There is a typo in test file
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-local-var-span.cpp#L117
`{{^3}}` should be `{{[^3]}}`
(It is copy-pasted to 3 more places in the test file.)
Some of the test cases fail when fixed and unfortunately it masks a real bug in `FixVarInitializerWithSpan`.
```
// If `Init` has a constant value that is (or equivalent to) a
// NULL pointer, we use the default constructor to initialize the span
// object, i.e., a `std:span` variable declaration with no initializer.
// So the fix-it is just to remove the initializer.
if (Init->isNullPointerConstant(Ctx,
// FIXME: Why does this function not ask for `const ASTContext
// &`? It should. Maybe worth an NFC patch later.
Expr::NullPointerConstantValueDependence::
NPC_ValueDependentIsNotNull)) {
std::optional InitLocation =
getEndCharLoc(Init, SM, LangOpts);
if (!InitLocation)
return {};
SourceRange SR(Init->getBeginLoc(), *InitLocation);
```
The problem is that for this form of initialization `int * ptr = nullptr;` the fixit removes only the "nullptr" but leaves "=" which makes the code syntactically invalid.
I can't think of a simple-enough solution that would cover all cases so filing issue for later.
`int * ptr = nullptr;`
`int * ptr {nullptr};`
The latter form is likely very uncommon but we still need to account for it.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81793] Faulty load-store forwarding with non byte-sized types
Issue
81793
Summary
Faulty load-store forwarding with non byte-sized types
Labels
miscompilation,
llvm:instcombine
Assignees
Reporter
bjope
Consider this example with a big-endian data layout:
```
target datalayout = "E"
define i8 @foo(ptr %p) {
entry:
store i9 -1, ptr %p, align 1
%r0 = load i8, ptr %p, align 1
ret i8 %r0
}
```
If running that through instcombine the result is:
```
target datalayout = "E"
define i8 @foo(ptr %p) {
store i9 -1, ptr %p, align 1
ret i8 -1
}
```
LLVM IR reference (nor the DataLayout) is describing where padding bits go when storing a non byte-sized type like that. In practice LLVM (at least the backends I know about) would (zero) extend up to the TypeStoreSize before storing the i9 to memory. So given a big-endian datalayout (and a 8-bit byte size) the above is a miscompile, as the load depends on the padding bits. Fora little-endian datalayout the optimization isn't totally wrong, but I don't think that LLVM should optimize this even for little-endian (afaik we have avioded such optimizations historically).
Here is an alive2 link showing that the above transformation is invalid: https://alive2.llvm.org/ce/z/LJpiuS
Assuming that we simply want to skip the transformation also for little endian, then a patch like this could solve the problem:
```
diff --git a/llvm/lib/Analysis/Loads.cpp b/llvm/lib/Analysis/Loads.cpp
index f1dda97aa32d..b63c5078f88e 100644
--- a/llvm/lib/Analysis/Loads.cpp
+++ b/llvm/lib/Analysis/Loads.cpp
@@ -534,9 +534,11 @@ static Value *getAvailableLoadStore(Instruction *Inst, const Value *Ptr,
TypeSize StoreSize = DL.getTypeSizeInBits(Val->getType());
TypeSize LoadSize = DL.getTypeSizeInBits(AccessTy);
-if (TypeSize::isKnownLE(LoadSize, StoreSize))
+if (DL.typeSizeEqualsStoreSize(Val->getType()) &&
+ TypeSize::isKnownLE(LoadSize, StoreSize)) {
if (auto *C = dyn_cast(Val))
return ConstantFoldLoadFromConst(C, AccessTy, DL);
+}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81795] LLDB python: 'unknown error' when calling EvaluateExpression
Issue
81795
Summary
LLDB python: 'unknown error' when calling EvaluateExpression
Labels
new issue
Assignees
Reporter
briandw
I'm trying to use the EvaluateExpression functionality from LLDB in Python.
It looks like it works but the return type is always Error.
Run the included sample below and it will call the function foo, but the result is 'unknown error'
```
from pathlib import Path
import lldb
import os
from lldb import SBError, SBThread
def main():
c_code = \
"""
#include
void foo(int i){
printf(\"Hello from foo %i\\n\", i);
}
int main(void){
return 0;
}
"""
#Compile the main code
main_file = Path("main.c")
main_file.write_text(c_code)
os.system('clang -g -O0 main.c -o main')
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(False)
target = debugger.CreateTarget("main")
break_point_main = target.BreakpointCreateByName("main")
launch_info = lldb.SBLaunchInfo(["./main"])
launch_info.SetWorkingDirectory(os.getcwd())
error = SBError()
process = target.Launch(launch_info, error)
assert target.IsValid()
assert process.IsValid()
assert break_point_main.IsValid()
state = process.GetState()
assert state == lldb.eStateStopped
thread: SBThread = process.GetSelectedThread()
frame = thread.GetSelectedFrame()
assert frame.IsValid()
assert thread.IsValid()
expr1: str = "int $x=4"
result_t = target.EvaluateExpression(expr1)
error_t: SBError = result_t.GetError()
print(f"result_t: {result_t}, {error_t}")
expr2: str = "(void)foo($x)"
result_f = frame.EvaluateExpression(expr2)
error_f: SBError = result_t.GetError()
print(f"result_t: {result_f}, {error_f}")
#Result should be something other than error
# foo prints out the message, as seen in the stdout, so why is there an error?
text = process.GetSTDOUT(1024)
print(text)
if __name__ == "__main__":
main()```
I'm running this on
lldb version 17.0.6
Python 3.11.0
Both mac M2 and a x86_64 Ubuntu machine.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81797] Backport "[LLD] [MinGW] Implement the --lto-emit-asm and -plugin-opt=emit-llvm options" to 18.x
Issue 81797 Summary Backport "[LLD] [MinGW] Implement the --lto-emit-asm and -plugin-opt=emit-llvm options" to 18.x Labels lld Assignees Reporter mstorsjo /cherry-pick d033366bd2189e33343ca93d276b40341dc39770 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81802] [HLSL] unbounded resource array get error when compile
Issue
81802
Summary
[HLSL] unbounded resource array get error when compile
Labels
HLSL
Assignees
Reporter
python3kgae
When compile following shader with clang --driver-mode=dxc -Tlib_6_6
```
RWBuffer b[];
float foo(int i) {
return b[i][i];
}
```
clang will report error " definition of variable with array type needs an explicit size or an initializer"
dxc compiles it successfully.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81804] LLD parser accepts too much in input section wildcard patterns
Issue 81804 Summary LLD parser accepts too much in input section wildcard patterns Labels bug, lld:ELF Assignees Reporter mysterymath We ran across an instance of strange parser behavior in LLD; it apparently is willing to accept the following as an input section wildcard: ``` *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.text*)) } PROVIDE_HIDDEN(__code_end = .) ``` There is a missing parenthesis after `.text*`; there should be three, not two. But LLD doesn't issue a diagnostic; it silently considers the all of the linker script up until the next paren as part of the pattern. This appears to be considerably more lenient than GNU LD's wildcard pattern: https://github.com/bminor/binutils-gdb/blob/363baa11378c6383eada19f6bc851fc7230c5dea/ld/ldlex.l#L95 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81809] Merge c007fbb19879f9b597b47ae772c53e53cdc65f29 into 18.x
Issue 81809 Summary Merge c007fbb19879f9b597b47ae772c53e53cdc65f29 into 18.x Labels new issue Assignees Reporter brad0 [PATCH] MipsAsmParser/O32: Don't add redundant $ to $-prefixed symbol in the la macro (#80644) When parsing the `la` macro, we add a duplicate `$` prefix in `getOrCreateSymbol`, leading to `error: Undefined temporary symbol $$yy` for code like: ``` xx: la $2,$yy $yy: nop ``` Remove the duplicate prefix. In addition, recognize `.L`-prefixed symbols as local for O32. See: #65020. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81813] The parallel compilation parameter "-j" is not applied to all modules
Issue 81813 Summary The parallel compilation parameter "-j" is not applied to all modules Labels new issue Assignees Reporter songdongsheng On a 16-core machine, although the parameter "-j3" is used, there are mostly 3 compilation processes during execution, but no less than 10 compilation processes can still be seen running. ``` cd /opt/llvm-build/llvm-18.x && /usr/bin/time -v ./llvm/utils/release/test-release.sh \ -release 18.1.0 \ -rc 2 \ -triple x86_64-unknown-linux-gnu \ -j 3 \ -use-ninja \ -no-checkout \ -no-compare-files ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81822] clang-format doesn't touch constructor format with braced initialization of base class and following member
Issue
81822
Summary
clang-format doesn't touch constructor format with braced initialization of base class and following member
Labels
clang-format
Assignees
Reporter
jacobsa
If I have this input, with a badly formatted constructor for `Bar`:
```c++
int some_int_with_a_very_long_name;
int some_other_int_with_a_very_long_name;
struct Foo {
explicit Foo(int, int);
};
struct Bar : Foo {
Bar() : Foo{
some_int_with_a_very_long_name,
some_other_int_with_a_very_long_name,
}, some_member(0) {}
int some_member;
};
```
Then clang-format won't change it; it leaves it as is, no matter how it's formatted. It should be formatting it like this:
```c++
Bar()
: Foo{
some_int_with_a_very_long_name,
some_other_int_with_a_very_long_name,
},
some_member(0) {}
};
```
This would be consistent with what clang-format already does correctly do if the initializer for `some_member` isn't there:
```c++
Bar()
: Foo{
some_int_with_a_very_long_name,
some_other_int_with_a_very_long_name,
} {}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81827] [BOLT] clang-nolbr.test sporadically fails
Issue 81827 Summary [BOLT] clang-nolbr.test sporadically fails Labels BOLT Assignees aaupov Reporter aaupov E.g. https://lab.llvm.org/buildbot/#/builders/244/builds/24658 Log: https://lab.llvm.org/buildbot/#/builders/244/builds/24658/steps/13/logs/FAIL__bolt-tests__clang-nolbr_test ``` + /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/bolt-tests/test/X86/Inputs/bf.cpp -O2 -std=c++11 -c -o /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp.out /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1d)[0xb91357] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN4llvm3sys17RunSignalHandlersEv+0x2f)[0xb90173] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0xb903f1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f8a1a642520] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0x3857bee] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0x354a37a] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0x3847331] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x7b)[0x340fbfb] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x4bc)[0x341e19a] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x33)[0x1ae4143] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x185)[0x2219375] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN5clang17EmitBackendOutputERNS_17DiagnosticsEngineERKNS_19HeaderSearchOptionsERKNS_14CodeGenOptionsERKNS_13TargetOptionsERKNS_11LangOptionsERKN4llvm10DataLayoutEPNSE_6ModuleENS_13BackendActionESt10unique_ptrINSE_17raw_pwrite_streamESt14default_deleteISM_EE+0x825)[0x22a3455] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0x2385f1e] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0x397424e] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN5clang13CodeGenAction13ExecuteActionEv+0x36)[0x2385986] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN5clang14FrontendAction7ExecuteEv+0x24)[0x2337034] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x120)[0x231c0e0] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x1a7)[0x23433a7] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x415)[0x2173c15] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp(main+0x4da)[0x1768eea] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f8a1a629d90] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f8a1a629e40] /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp[0x2172d29] Stack dump: 0. Program arguments: /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name bf.cpp -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/Output/clang-nolbr.test.tmp.gcno -resource-dir /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/tools/bolttests/X86/lib/clang/6.0.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11 -internal-isystem
