[llvm-bugs] [Bug 120857] [Clang] parser error
Issue
120857
Summary
[Clang] parser error
Labels
clang
Assignees
Reporter
TrofiMichael
I'm trying to compile the following code:
```
class BigInteger {
friend bool operator==(const BigInteger&, const BigInteger&);
friend class Rational;
};
bool operator==(const BigInteger&, const BigInteger&) = default;
int main() {}
```
With clang++ -std=c++20
The compiler gives a parser error.
The next three files contain a compilation log, a cpp file and a sh file.
- [compilation_log.txt](https://github.com/user-attachments/files/18219989/compilation_log.txt)
- [clang_issue_cpp.txt](https://github.com/user-attachments/files/18220002/clang_issue_cpp.txt)
- [clang_issue_sh.txt](https://github.com/user-attachments/files/18220004/clang_issue_sh.txt)
All the following versions of clang fail to compile this:
- clang 20.0.0git
- x86-64 clang from 19.1.0 to 15.0.0
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120863] [clang-tidy] Check request: don't capture `this` by a field of default copyable class
Issue
120863
Summary
[clang-tidy] Check request: don't capture `this` by a field of default copyable class
Labels
clang-tidy
Assignees
Reporter
denzor200
Assume the user defined class:
```
struct A {
std::string content;
std::function captured;
A() {
captured =
[this]() { // INCORRECT
perform();
};
}
void perform() { std::cout << content << std::endl; }
};
```
Since it's copy constructor was generated by the compiler, it's behaviour might be unexpected for some user and even can produce a crash with SIGSEGV:
```
A a;
a.content = "Hello world";
a.captured();
A a1 = a;
a1.content = "Test";
a1.captured(); // will print "Hello world" which might be unexpected
```
```
auto a = std::make_unique();
a->content = "Hello world";
a->captured();
auto b = std::make_unique(*a);
a.reset();
b->content = "Ooooups!";
b->captured(); // UB
```
The way to fix it is to provide manually written copy constructor and assignment operator:
```
A(const A& oth)
: content(oth.content)
, captured([this](){perform();}) {}
A& operator=(const A& oth) {
if (this != &oth) {
content = oth.content;
captured = [this](){perform();};
}
}
```
Making you class noncopyable also protect you from the bug:
```
A(const A& oth) = delete;
A& operator=(const A& oth) = delete;
```
But before you fix it you must discover it in the code, so the clang-tidy check in bugprone section would be nice addition.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120869] [AArch64][GISel] Handle bitreverse intrinsic for some vector types
Issue 120869 Summary [AArch64][GISel] Handle bitreverse intrinsic for some vector types Labels new issue Assignees Reporter madhur13490 Parent issue: https://github.com/llvm/llvm-project/issues/115133 Godbolt link: https://godbolt.org/z/nP8jssKh8 This intrinsic is missing support for v2i64, v4i16 etc. as shown by the above godbolt link. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120870] diagnostics: clang loses provenance of inline asm when issuing diagnostics
Issue
120870
Summary
diagnostics: clang loses provenance of inline asm when issuing diagnostics
Labels
clang
Assignees
Reporter
lf-
```
$ cat test.c
asm ("foo");
int main(void) {
}
$ clang test.c
:1:1: error: invalid instruction mnemonic 'foo'
1 | foo
| ^
1 error generated.
```
When issuing diagnostics, clang loses where the inline asm is. It should issue a hint of where it starts in the source file or something like that. This issue was encountered while hunting down a diagnostic in production code:
```
:2:41: error: expected '%' or ""
2 | .pushsection ".debug_gdb_scripts", "MS",@progbits,1
| ^
:102:12: error: .popsection without corresponding .pushsection
102 | .popsection
|^
```
If this happens in CI for a weird platform (which, if you're having a bad day, of course it is), it necessitates preprocessing the file and hopefully finding where this thing came from, which may require dismantling a build system to get access to even do so; fun for all ages. n.b. the above is probably another bug, but I will figure out what it is and file it separately.
```
$ clang --version
clang version 18.1.8
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/im1yhwr0p1j7r5mi47cyn4sq3wmhzkzf-cl
ang-18.1.8/bin
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120853] [clang-tidy] Check request: detect incorrect creating of `std::enable_shared_from_this` objects
Issue
120853
Summary
[clang-tidy] Check request: detect incorrect creating of `std::enable_shared_from_this` objects
Labels
clang-tidy
Assignees
Reporter
denzor200
```
struct A : std::enable_shared_from_this {
};
std::shared_ptr a2 = std::make_shared(); // OK
std::shared_ptr a1(new A); // OK
auto* a3 = new A; // INCORRECT
A a; // INCORRECT
```
These two incorrect usages might contain hidden SEGFAULT.
Suppose it easily to detect by clang-tidy and might be really helpful.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120846] [Clang] The assignment to object outside its lifetime is not allowed in a constant expression error while initializing heap allocated memory
Issue
120846
Summary
[Clang] The assignment to object outside its lifetime is not allowed in a constant _expression_ error while initializing heap allocated memory
Labels
clang
Assignees
Reporter
kridenberg
Below I wrote down a simplified version of the code I try to implement in the production environment.
The code below is compiled with the latest GCC and the latest MSVC.
Minimal reproducible example here: [https://godbolt.org/z/za3vKnxzj](url)
```cpp
#include
#include
#include
#include
struct buffer
{
constexpr buffer(char16_t const* values, size_t const count)
: m_byte_count {count * sizeof(char16_t)}
, m_bytes {std::allocator().allocate(m_byte_count)}
{
struct bytes
{
std::byte bytes[2];
};
for (std::size_t index = 0; index < count; ++index)
{
bytes const bitwise = std::bit_cast(values[index]);
m_bytes[(index * sizeof(char16_t)) + 0] = bitwise.bytes[0];
m_bytes[(index * sizeof(char16_t)) + 1] = bitwise.bytes[1];
}
}
constexpr auto compute() const -> int
{
int result = 0;
for (std::size_t index = 0; index < m_byte_count; ++index)
{
result = result ^ static_cast(m_bytes[index]);
}
return result;
}
constexpr ~buffer()
{
std::allocator().deallocate(m_bytes, m_byte_count);
}
std::size_t m_byte_count;
std::byte* m_bytes;
};
consteval auto compute(char16_t const* values, size_t const count) -> int
{
buffer b(values, count);
return b.compute();
}
auto main() -> int
{
constexpr auto value = compute(u"oadpoadopa", 10);
std::cout << value << std::endl;
return 0;
}
```
```
:53:17: error: constexpr variable 'value' must be initialized by a constant _expression_
53 | constexpr auto value = compute(u"oadpoadopa", 10);
|^ ~~
:20:44: note: assignment to object outside its lifetime is not allowed in a constant _expression_
20 | m_bytes[(index * sizeof(char16_t)) + 0] = bitwise.bytes[0];
| ^~
:47:9: note: in call to 'buffer(&u"oadpoadopa"[0], 10)'
47 | buffer b(values, count);
|^~~~
:53:25: note: in call to 'compute(&u"oadpoadopa"[0], 10)'
53 | constexpr auto value = compute(u"oadpoadopa", 10);
| ^~
:53:25: error: call to consteval function 'compute' is not a constant _expression_
53 | constexpr auto value = compute(u"oadpoadopa", 10);
| ^
:20:44: note: assignment to object outside its lifetime is not allowed in a constant _expression_
20 | m_bytes[(index * sizeof(char16_t)) + 0] = bitwise.bytes[0];
| ^~
:47:9: note: in call to 'buffer(&u"oadpoadopa"[0], 10)'
47 | buffer b(values, count);
|^~~~
:53:25: note: in call to 'compute(&u"oadpoadopa"[0], 10)'
53 | constexpr auto value = compute(u"oadpoadopa", 10);
| ^~
2 errors generated.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120830] How do I use IWYU pragmas properly for private includes?
Issue 120830 Summary How do I use IWYU pragmas properly for private includes? Labels new issue Assignees Reporter UtkarshVerma I have this repo ([dwmblocks-async](https://github.com/UtkarshVerma/dwmblocks-async)) which generates a few errors when I run clang-tidy. ```console $ clang-tidy include/signal-handler.h 551 warnings generated. /home/subaru/.local/src/dwmblocks/include/signal-handler.h:4:1: warning: included header signal.h is not used directly [misc-include-cleaner] 4 | #include // IWYU pragma: private; include | ^~~ 5 | /home/subaru/.local/src/dwmblocks/include/signal-handler.h:9:9: warning: no header providing "sigset_t" is directly included [misc-include-cleaner] 4 | #include // IWYU pragma: private; include 5 | 6 | #include "block.h" 7 | #include "timer.h" 8 | 9 | typedef sigset_t signal_set; | ^ Suppressed 550 warnings (549 in non-user code, 1 NOLINT). Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well. ``` I tried doing adding the appropriate IWYU pragmas to signal-handler.h. https://github.com/UtkarshVerma/dwmblocks-async/blob/main/include/signal-handler.h ```h #include // IWYU pragma: private; include ``` But this doesn't seem to work. Am I doing something wrong? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120839] [lldb-dap] VS Code extension does not work (Couldn't find a debug adapter descriptor)
Issue
120839
Summary
[lldb-dap] VS Code extension does not work (Couldn't find a debug adapter descriptor)
Labels
new issue
Assignees
Reporter
kyrylo-sovailo
Hi! I'm testing all popular VS Code extensions I could find and unfortunately LLDB DAP fails to launch. Here is my launch.json entry:
```
"extension_name": "LLDB DAP",
"name": "LLDB Debug (LLDB DAP)",
"type": "lldb-dap",
"request": "launch",
"initCommands": [ "shell make -C ${workspaceFolder} all" ],
"program": "${workspaceFolder}/build/main_clang",
"cwd": "${workspaceFolder}/build",
"args": [ "TEST" ],
"env": { "DEBUG_SANDBOX_TEST" : "TEST" }
```
When I press the debug button, two things happen. In the centre of the screen I see an error window with `Couldn't find a debug adapter descriptor for debug type lldb-dap (extension might have failed to activate)`.
Also in the lower right corner I see VSCode error with `Debug adapter path: /home/kyrylo/.vscode/extensions/llvm-vs-code-extensions.lldb-dap-0.2.8/bin/lldb-dap is not a valid file`.
It is a rather normal VSCode (1.95.3) installation on Gentoo. LLDB DAP is the only installed extension. `lldb` is installed and works, `lldb-dap` is installed and runs.
Cheers.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120836] [Clang] [NVPTX] [Windows] Compilation errors with CUDA NVPTX backend and MSVC headers
Issue
120836
Summary
[Clang] [NVPTX] [Windows] Compilation errors with CUDA NVPTX backend and MSVC headers
Labels
clang
Assignees
Reporter
blinkfrog
**Describe the bug**
When compiling CUDA code with Clang's NVPTX backend on Windows using MSVC headers, multiple errors occur related to the `__builtin_va_list` type not being compatible with MSVC's `va_list`. This appears to be a mismatch in how Clang and MSVC handle `va_list` when compiling CUDA device code.
**To Reproduce**
Steps to reproduce the behavior:
1. Use the following simple CUDA program (`test.cu`):
```
#include
#include
__global__ void addKernel(int *c, const int *a, const int *b) {
int i = threadIdx.x;
c[i] = a[i] + b[i];
}
int main() {
const int arraySize = 5;
int a[arraySize] = {1, 2, 3, 4, 5};
int b[arraySize] = {10, 20, 30, 40, 50};
int c[arraySize] = {0};
int *dev_a = nullptr, *dev_b = nullptr, *dev_c = nullptr;
cudaMalloc((void**)&dev_a, arraySize * sizeof(int));
cudaMalloc((void**)&dev_b, arraySize * sizeof(int));
cudaMalloc((void**)&dev_c, arraySize * sizeof(int));
cudaMemcpy(dev_a, a, arraySize * sizeof(int), cudaMemcpyHostToDevice);
cudaMemcpy(dev_b, b, arraySize * sizeof(int), cudaMemcpyHostToDevice);
addKernel<<<1, arraySize>>>(dev_c, dev_a, dev_b);
cudaMemcpy(c, dev_c, arraySize * sizeof(int), cudaMemcpyDeviceToHost);
std::cout << "Results: ";
for (int i = 0; i < arraySize; ++i) {
std::cout << c[i] << " ";
}
std::cout << std::endl;
cudaFree(dev_a);
cudaFree(dev_b);
cudaFree(dev_c);
return 0;
}
```
2. Compile the code using Clang with the following command (adjust paths according to your environment):
```
clang++ -std=c++14 --cuda-gpu-arch=sm_75 --cuda-path="C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4" -L"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\lib\x64" -lcudart_static -ldl -lrt -pthread test.cu -o test.exe
```
3. Observe the following errors (truncated):
```
In file included from :1:
In file included from C:\llvm\lib\clang\19\include\__clang_cuda_runtime_wrapper.h:472:
In file included from C:\llvm\lib\clang\19\include\__clang_cuda_cmath.h:16:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\limits:12:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\cwchar:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\cstdio:11:
In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\stdio.h:13:
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\corecrt_wstdio.h:486:24: error: non-const lvalue
reference to type '__builtin_va_list' cannot bind to a value of unrelated type 'va_list' (aka 'char *')
486 | __crt_va_start(_ArgList, _Locale);
|^~~~
C:\llvm\lib\clang\19\include\vadefs.h:39:54: note: expanded from macro '__crt_va_start'
39 | #define __crt_va_start(ap, param) __builtin_va_start(ap, param)
| ^~
In file included from :1:
In file included from C:\llvm\lib\clang\19\include\__clang_cuda_runtime_wrapper.h:472:
In file included from C:\llvm\lib\clang\19\include\__clang_cuda_cmath.h:16:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\limits:12:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\cwchar:11:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include\cstdio:11:
In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\stdio.h:13:
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\corecrt_wstdio.h:488:22: error: non-const lvalue
reference to type '__builtin_va_list' cannot bind to a value of unrelated type 'va_list' (aka 'char *')
488 | __crt_va_end(_ArgList);
| ^~~~
(truncated)
```
**Expected behavior**
The program should compile without errors related to standard library headers.
**Observed behavior**
Compilation fails with the above `va_list` errors, indicating a mismatch between Clang’s built-in types and MSVC’s definitions in CUDA device mode.
**Environment:**
LLVM Clang version: 19.1.6
CUDA toolkit version: 12.4
Visual Studio version: 2022 Community Edition 17.12.3
Windows SDK version: 10.0.22621.0
Command used for compilation:
```
clang++ -std=c++14 --cuda-gpu-arch=sm_75 --cuda-path="C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4" -L"C:\Program
[llvm-bugs] [Bug 120837] No good way to express atomicrmw on pointers
Issue 120837 Summary No good way to express atomicrmw on pointers Labels new issue Assignees Reporter RalfJung In Rust, we'd like to add atomic RMW operations on pointers. For instance, we have an atomic fetch_add that is supposed to behave like a version of `getelementptr` that atomically adjusts an in-memory pointer. However, when generating LLVM IR we currently have to do the `atomicrmw` at type `i64`. This has multiple problems: - It requires casting the pointer argument to an integer, which is an operation with non-trivial consequences (the pointee is irrevocably "exposed" by this). - Worse, it acts on a pointer stored in-memory as if it was an integer. The consequences of this for pointer provenance (the concept of which pointer is "derived from" which other pointer) are unclear, but naive answers are known to be wrong (if you are curious about this, I wrote a [series](https://www.ralfj.de/blog/2020/12/14/provenance.html) of [blog posts](https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html) on the subject a while ago) - It can't really work on CHERI (not even after using the proper size, `i64`), where pointers and integers are decidedly different objects (not sure if CHERI has special instructions to atomically update pointers; if not, this would have to be lowered to a CAS loop) It would be great if LLVM had a way to directly represent the desired semantics here: an `atomicrmw add`, or instance, that takes an integer argument but is specified to treat the memory contents as a pointer, performing `getelementptr`-style arithmetic on it, and returns something of type `ptr`. Bitwise operations wold also make sense, they would behave like `ptrmask`. That avoids any ambiguities around provenance / which pointer is "derived from" which other pointer. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120847] Question: Add target specific include/library directories by default.
Issue 120847 Summary Question: Add target specific include/library directories by default. Labels Assignees Reporter WildCard65 How would I go about either modifying or instructing clang to add directories to its default include/library search paths that are suffixed with the target triple (default or --target=). I found a potential solution inside Driver/Toolchains but is there a generic simple solution to accomplish this, atleast for linux/bsd. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120854] [OpenMP][IR] OMP: Error #132: Thread identifier invalid.
Issue
120854
Summary
[OpenMP][IR] OMP: Error #132: Thread identifier invalid.
Labels
Assignees
Reporter
wesuRage
I'm trying to make parallel loops with different scheduling policies. My generated LLVM looks like this:
```llvm
; ModuleID = 'GalaxyJIT'
source_filename = "GalaxyJIT"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@omp_ident = private constant { i32, i32, i32, i32, ptr } { i32 0, i32 514, i32 0, i32 22, ptr null }
define i32 @main() {
entry:
br label %preloop
preloop: ; preds = %entry
%i = alloca i32, align 4
store i32 0, ptr %i, align 4
%i1 = alloca i32, align 4
store i32 0, ptr %i1, align 4
br label %cond
cond: ; preds = %update, %preloop
%i2 = load i32, ptr %i1, align 4
%loopcond = icmp slt i32 %i2, 10
br i1 %loopcond, label %body, label %endloop
body: ; preds = %cond
call void @__kmpc_for_static_init_4(ptr @omp_ident, i32 0, i32 33, ptr %i1, i32 10, ptr null, ptr null, i32 1, i32 1)
%updatedLoopVar = add i32 %i2, 1
store i32 %updatedLoopVar, ptr %i1, align 4
br label %update
update: ; preds = %body
br label %cond
endloop: ; preds = %cond
ret i32 0
}
declare void @__kmpc_for_static_init_4(ptr, i32, i32, ptr, i32, ptr, ptr, i32, i32)
```
Then i compile the generated object file with:
```bash
clang -fopenmp -L/usr/lib/llvm-19/lib/ output.o -o executable
```
And when I run it...
```
OMP: Error #132: Thread identifier invalid.
Assertion failure at kmp_runtime.cpp(6993): __kmp_registration_flag != 0.
OMP: Error #13: Assertion failure at kmp_runtime.cpp(6993).
OMP: Hint Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see https://github.com/llvm/llvm-project/issues/.
```
If more information is needed, like how my source code looks like, let me know and I will send it.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120855] Missed tysan violation with optimization
Issue
120855
Summary
Missed tysan violation with optimization
Labels
new issue
Assignees
Reporter
thesamesam
With `-O0 -fsanitize=type`, we detect the violation correctly, but fail to with `-O1` or greater:
```
#include
typedef struct k {
int a;
int b;
} k;
typedef struct l {
bool a;
bool b;
} l;
k my_k;
l my_l;
void frobnicate_the_struct(k *my_k) {
int a = ((k*) &my_k)->a;
__builtin_printf("got k.a=%d\n", a);
}
int main() {
frobnicate_the_struct((k*)&my_l);
}
```
```
$ clang -O0 -fsanitize=type a.c -o a && ./a
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x7ffcfff2a198 (pc 0x5f6739b118d1 bp 0x7ffcfff2a110 sp 0x7ffcfff2a0b8 tid 1)
READ of size 4 at 0x7ffcfff2a198 with type int (in k at offset 0) accesses an existing object of type p1 _ZTS1k
#0 0x5f6739b118d0 (/app/output.s+0x2a8d0)
got k.a=977714280
```
```
$ clang -O1 -fsanitize=type a.c -o a && ./a
got k.a=1389137000
```
godbolt: https://godbolt.org/z/cYPT3vYnY
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120856] [lldb] A typo in the detection of `this` arguments?
Issue
120856
Summary
[lldb] A typo in the detection of `this` arguments?
Labels
new issue
Assignees
Reporter
SingleAccretion
I've encountered what seems like a bug in this code:
https://github.com/llvm/llvm-project/blob/fd784726db70a5155594c32ee839b8807fafd87d/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L3140-L3147
In my case, the entry for "this" looked like this:
```
0x01a4: DW_TAG_formal_parameter
DW_AT_artificial (0x01)
DW_AT_type (0x01e0 "WebAssemblyPtrWrapper")
...
0x01e0: DW_TAG_structure_type
DW_AT_name ("WebAssemblyPtrWrapper")
DW_AT_byte_size (0x04)
```
And was still picked up, despite the seeming intention of filtering out non-pointer arguments.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120867] [clang-tidy] Ignore `modernize-use-integer-sign-comparison` between signed wide type and unsigned narrow type
Issue
120867
Summary
[clang-tidy] Ignore `modernize-use-integer-sign-comparison` between signed wide type and unsigned narrow type
Labels
clang-tidy
Assignees
Reporter
zufuliu
For following code (online at https://godbolt.org/z/evGzzTdb7), I'd like the checker emits no warnings for `foo1` and `foo2` (the narrow `y` implicitly promoted to `int`), also `bar1` missed the warning even with `-fsigned-char`.
```c++
bool foo1(int x, unsigned char y) {
return x == y;
}
bool foo2(int x, unsigned short y) {
return x == y;
}
bool bar1(unsigned int x, char y) {
return x == y;
}
bool bar2(unsigned int x, short y) {
return x == y;
}
```
current output:
```console
[:2:12: warning: comparison between 'signed' and 'unsigned' integers [modernize-use-integer-sign-comparison]](_javascript_:;)
1 | bool foo1(int x, unsigned char y) {
2 | return x == y;
|^ ~~
|std::cmp_equal( , )
[:5:12: warning: comparison between 'signed' and 'unsigned' integers [modernize-use-integer-sign-comparison]](_javascript_:;)
5 | return x == y;
|^ ~~
|std::cmp_equal( , )
[:11:12: warning: comparison between 'signed' and 'unsigned' integers [modernize-use-integer-sign-comparison]](_javascript_:;)
11 | return x == y;
|^ ~~
|std::cmp_equal( , )
3 warnings generated.
```
CC @qt-tatiana as author of the checker (PR #113144).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120868] clang doesn't support the full libmvec in glibc
Issue
120868
Summary
clang doesn't support the full libmvec in glibc
Labels
clang
Assignees
Reporter
hjl-tools
Unlike GCC which reads macros defined in to determine the libmvect interface in glibc,
clang 19 hard-codes the libmvec interface at clang build-time. When the new functions are added to libmvec, they
can't be used by clang 19:
```
[hjl@gnu-tgl-3 tmp]$ cat x.c
#define LIBMVEC_TYPE double
#define LIBMVEC_FUNC asin
#include
#define N 1000
LIBMVEC_TYPE x[N], c[N];
int
main (void)
{
int i;
for(i = 0; i < N; i++)
c[i] = i / 3;
#pragma omp simd
for(i = 0; i < N; i++)
x[i] = LIBMVEC_FUNC (c[i]);
return 0;
}
[hjl@gnu-tgl-3 tmp]$ clang -S -O3 -ffast-math x.c -fopenmp
x.c:10:1: warning: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering [-Wpass-failed=transform-warning]
10 | main (void)
| ^
1 warning generated.
[hjl@gnu-tgl-3 tmp]$ gcc -S -O3 -ffast-math x.c -fopenmp
[hjl@gnu-tgl-3 tmp]$ grep call x.s
call _ZGVbN2v_asin
[hjl@gnu-tgl-3 tmp]$
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120871] pushsection idiom for GDB scripts not supported by integrated `as` and llvm-mc for arm targets
Issue
120871
Summary
pushsection idiom for GDB scripts not supported by integrated `as` and llvm-mc for arm targets
Labels
new issue
Assignees
Reporter
lf-
```
$ armv7l-unknown-linux-gnueabihf-cc test.c
:1:41: error: expected '%' or ""
1 | .pushsection ".debug_gdb_scripts", "MS",@progbits,1
| ^
:4:12: error: .popsection without corresponding .pushsection
4 | .popsection
|^
2 errors generated.
$ armv7l-unknown-linux-gnueabihf-cc -no-integrated-as test.c
```
There is an assembly idiom as follows which works with both `-no-integrated-as` and `-integrated-as` on the Clang x86 target, but not on the armv7 target. This causes some build breakage of code using this idiom which is accepted by GNU `as` and Clang with `-no-integrated-as`.
Code:
```c
asm (
".pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n"
".byte 1 /* Python */\n"
".asciz \"whatkillsusmakesusdeader.py\"\n"
".popsection");
int main(void) {
}
```
Repro using llvm-mc:
```asm
.pushsection ".debug_gdb_scripts", "MS",@progbits,1
.byte 1 /* Python */
.asciz "whatkillsusmakesusdeader.py"
.popsection
```
```
$ llvm-mc --arch=x86 /tmp/test.s
.text
.section.debug_gdb_scripts,"MS",@progbits,1
.byte 1
.ascii "whatkillsusmakesusdeader.py"
.byte 0
.text
$ llvm-mc --arch=arm /tmp/test.s
.text
/tmp/test.s:1:41: error: expected '%' or ""
.pushsection ".debug_gdb_scripts", "MS",@progbits,1
^
.byte 1
.ascii "whatkillsusmakesusdeader.py"
.byte 0
/tmp/test.s:4:12: error: .popsection without corresponding .pushsection
.popsection
^
```
Compare:
```
$ » armv7l-unknown-linux-gnueabihf-as test.s
$ » armv7l-unknown-linux-gnueabihf-as --version
GNU assembler (GNU Binutils) 2.43.1
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `armv7l-unknown-linux-gnueabihf'.
```
```
$ armv7l-unknown-linux-gnueabihf-cc --version
clang version 18.1.8
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /nix/store/02xcipa0v0dc1qv9kdihdkffq7crsjr6-clang-18.1.8/bin
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120875] Clang (C23): Attributes with unknown "attribute-prefix" should not raise "-Wunknown-attributes"
Issue
120875
Summary
Clang (C23): Attributes with unknown "attribute-prefix" should not raise "-Wunknown-attributes"
Labels
clang
Assignees
Reporter
namandixit
With `--std=c23`, when using attributes with an arbitrary `attribute-prefix`, Clang raises the warning `-Wunknown-attributes` as shown below.
```sh
$ cat test.c
[[cthrough::hello(bye((no)) go(away((please, cthrough::alvida(la la la la)]]
int main (void)
{
return 3;
}
$
$
$ clang --std=c23 test.c -o exe
test.c:1:3: warning: unknown attribute 'hello' ignored [-Wunknown-attributes]
1 | [[cthrough::hello(bye((no)) go(away((please, cthrough::alvida(la la la la)]]
| ^~~
test.c:1:50: warning: unknown attribute 'alvida' ignored [-Wunknown-attributes]
1 | [[cthrough::hello(bye((no)) go(away((please, cthrough::alvida(la la la la)]]
| ^~~~
```
The whole point of `attribute-prefix`s is to be able to use attributes for multiple compilers without a `#ifdef`-hell. Thus, there is no reason for this warning to be raised. And if a warning has to be raised, it should be a different one (perhaps `-Wunknown-attribute-prefix`) such that it can selectively be disabled (since `-Wunknown-attributes` is useful in case of misspelled attributes in general).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
