[llvm-bugs] [Bug 138492] [Clang Tidy][Efficiency] Clang tidy wastes endless time on checking non-usercode
Issue 138492 Summary [Clang Tidy][Efficiency] Clang tidy wastes endless time on checking non-usercode Labels clang Assignees Reporter hasselmm * Actual behavior: Clang Tidy searches for errors in non-user code. * Expected behavior: Clang Tidy only does the abolut minimum when processing non-user code for efficency Clang Tidy is slow. Very slow. So actually it's very surprising to read such messages: ``` Suppressed 48487 warnings (48482 in non-user code, 5 NOLINT) ``` So Clang Tidy tells me proudly it has wasted endless time on identifying 48.487 errors in non-user code. Code I am most likely never every going to fix. Code that I most likely cann't even fix without causing serious problem. This is bizzare, to put it nicely. Efficency is key to make using Clang Tidy a no-brainer, a mandatory task in C++ programming. Therefore Clang Tidy should spend as little time as possible on non-user code. It should just skip non-user code without even trying to analyse it for flaws. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138636] Missed optimization: conditional store of zext(i1) not folded to constant zero when i1 is known false
Issue
138636
Summary
Missed optimization: conditional store of zext(i1) not folded to constant zero when i1 is known false
Labels
new issue
Assignees
Reporter
GINN-Imp
The following reduced IR is derived from https://github.com/c3lang/c3c/blob/125436d23ef9b7f69837a00ffec168c52839a1dc/src/compiler/bigint.c#L777
Godbolt: https://godbolt.org/z/jTWv4o5n8
Missed optimization: `store i8 %4, ptr %2, align 1` --> `store i8 0, ptr %2, align 1`
alive2 proof: https://alive2.llvm.org/ce/z/ZQ5aad
```llvm
define void @src(ptr writeonly captures(none) initializes((0, 1)) %0, i1 %1, ptr writeonly captures(none) %2) local_unnamed_addr #0 {
%4 = zext i1 %1 to i8
store i8 %4, ptr %0, align 1
br i1 %1, label %6, label %5
5: ; preds = %3
store i8 %4, ptr %2, align 1
br label %6
6:; preds = %5, %3
ret void
}
```
opt-trunk -O3 generates:
```llvm
define void @src(ptr writeonly captures(none) initializes((0, 1)) %0, i1 %1, ptr writeonly captures(none) %2) local_unnamed_addr #0 {
%4 = zext i1 %1 to i8
store i8 %4, ptr %0, align 1
br i1 %1, label %6, label %5
5: ; preds = %3
store i8 %4, ptr %2, align 1
br label %6
6: ; preds = %5, %3
ret void
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138552] [VE] Corrupted LaneBitmask representing regLiveUnits for VE
Issue 138552 Summary [VE] Corrupted LaneBitmask representing regLiveUnits for VE Labels Assignees Reporter vg0204 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138493] [OpenMP] Assertion `(SemaRef.CurContext->isDependentContext() || B.builtAll()) && "loop exprs were not built"' failed.
Issue
138493
Summary
[OpenMP] Assertion `(SemaRef.CurContext->isDependentContext() || B.builtAll()) && "loop exprs were not built"' failed.
Labels
new issue
Assignees
Reporter
k-arrows
I am not confident if this is a duplicate of https://github.com/llvm/llvm-project/issues/138445, because the backtrace looks a bit different.
Reproducer:
https://godbolt.org/z/83rdTfMod
```cpp
void f(void) {
#pragma omp simd collapse(a)
for (int i = 0; i < 10; i++)
;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138494] SPARC -target-feature +vis breaks flang build on Linux/sparc64
Issue 138494 Summary SPARC -target-feature +vis breaks flang build on Linux/sparc64 Labels flang Assignees Reporter rorth A 2-stage build with `flang` included is currently broken on Linux/sparc64 with tons of errors like ``` error: current translation unit is compiled with the target feature '+vis' but the AST file 'tools/flang/lib/Parser/CMakeFiles/FortranParser.dir/cmake_pch.hxx.pch' was not ``` I could trace this to the fact that the object file creating is run with `clang-21 -cc1 -triple sparc64-unknown-linux-gnu -emit-obj -target-feature +vis` while the pch generation uses `clang-21 -cc1 -triple sparc64-unknown-linux-gnu -emit-pch` without the `-target-feature +vis`, thus the inconsistency. Even without `flang`, there are three testsuite regressions showing the same error: ``` Clang :: ClangScanDeps/modules-symlink.c Clang :: ClangScanDeps/prebuilt-modules-in-stable-dirs.c Clang :: SemaCXX/warn-unused-local-typedef-serialize.cpp ``` While I managed to get further along with the attached preliminary patch, which adds the missing option for `-emit-pch` and `-emit-llvm` (which fixes the `flang` build), this introduces tons of new regressions instead: ``` Clang :: ClangScanDeps/module-format.c Clang :: ClangScanDeps/modules-pch-common-submodule.c Clang :: ClangScanDeps/modules-pch-common-via-submodule.c Clang :: ClangScanDeps/modules-pch-dangling.c Clang :: ClangScanDeps/modules-pch-imports.c Clang :: ClangScanDeps/modules-pch.c Clang :: ClangScanDeps/optimize-vfs-pch.m Clang :: Index/pch-with-errors.c Clang :: PCH/different-diagnostic-level.c Clang :: PCH/gch-probe.c Clang :: PCH/pch-dir.c Clang :: Tooling/pch.cpp ``` Now the `.pch` files are correctly built with `-target-feature +vis`, but the TUs are claimed to be not and I have no idea what's going on. Fortunately, Solaris/sparcv9 isn't affected because for unknown reasons commit 385311625945e65990bd60bea76a045dcaf3f47b, which introduced `-target-feature +vis`, doesn't pass that option on Solaris. It seems other targets are less affected because unlike the `sparcv9` case they only enable `-target-feature` with special flags and not in general. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138509] [14.0.0 regression] Compiler hang at -O3 on x86_64-linux-gnu
Issue
138509
Summary
[14.0.0 regression] Compiler hang at -O3 on x86_64-linux-gnu
Labels
new issue
Assignees
Reporter
KavyaChopra04
Godbolt link: https://godbolt.org/z/d3EhhfEEK
```
[618] % clangtk -v
clang version 21.0.0git (https://github.com/llvm/llvm-project.git 41647412c6a4091080fd47b0f554adc5c54b4b54)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/software/local/clang-trunk/bin
Build config: +assertions
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64
[619] %
[619] % timeout -s 9 20 clangtk -O3 small.c
Killed
[620] %
[620] % cat small.c
int a, b, c, d, e;
int main() {
f:
goto g;
h:
goto i;
j:
goto k;
g:
if (e)
goto l;
goto m;
k:
c = 1;
if (d >= 0)
goto o;
n:
goto q;
p:
c = c * 3;
e = c - 1;
if (e * a >= 0)
goto s;
i:
goto n;
r:
goto h;
l:
goto j;
m:
goto r;
s:
b = a * c;
if (b >= 0)
goto p;
goto k;
o:
b = e;
if (e * d)
goto f;
goto s;
q:;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138513] DAGCombiner/SimplifyDemandedBits making ISel DAG more poisonous for bitcasted vector
Issue
138513
Summary
DAGCombiner/SimplifyDemandedBits making ISel DAG more poisonous for bitcasted vector
Labels
llvm:SelectionDAG
Assignees
bjope
Reporter
bjope
Consider IR in this example:
```
define void @bar(i16 %a, ptr %p) {
entry:
%.upto4 = insertelement <8 x i16> , i16 %a, i64 4
%.upto5 = insertelement <8 x i16> %.upto4, i16 5, i64 5
%.upto6 = insertelement <8 x i16> %.upto5, i16 6, i64 6
%.upto7 = insertelement <8 x i16> %.upto6, i16 7, i64 7
%bitcast = bitcast <8 x i16> %.upto7 to i128
%lshr = lshr i128 %bitcast, 48
%trunc = trunc i128 %lshr to i32
store i32 %trunc, ptr %p
ret void
}
```
When running `llc -debug ...` on the above we see this:
```
Initial selection DAG: %bb.0 'bar:entry'
SelectionDAG has 33 nodes:
t0: ch,glue = EntryToken
t24: i128 = Constant<48>
t28: i64 = Constant<0>
t11: v8i16 = BUILD_VECTOR Constant:i16<0>, Constant:i16<1>, Constant:i16<2>, Constant:i16<3>, poison:i16, poison:i16, poison:i16, poison:i16
t2: i32,ch = CopyFromReg t0, Register:i32 %0
t3: i16 = truncate t2
t13: v8i16 = insert_vector_elt t11, t3, Constant:i64<4>
t16: v8i16 = insert_vector_elt t13, Constant:i16<5>, Constant:i64<5>
t19: v8i16 = insert_vector_elt t16, Constant:i16<6>, Constant:i64<6>
t22: v8i16 = insert_vector_elt t19, Constant:i16<7>, Constant:i64<7>
t23: i128 = bitcast t22
t26: i128 = srl t23, Constant:i8<48>
t27: i32 = truncate t26
t5: i64,ch = CopyFromReg t0, Register:i64 %1
t30: ch = store<(store (s32) into %ir.p)> t0, t27, t5, undef:i64
t32: ch = X86ISD::RET_GLUE t30, TargetConstant:i32<0>
...
Combining: t27: i32 = truncate t26
Replacing.2 t22: v8i16 = insert_vector_elt t19, Constant:i16<7>, Constant:i64<7>
With: t19: v8i16 = insert_vector_elt t16, Constant:i16<6>, Constant:i64<6>
Combining: t27: i32 = truncate t26
Replacing.2 t19: v8i16 = insert_vector_elt t16, Constant:i16<6>, Constant:i64<6>
With: t16: v8i16 = insert_vector_elt t13, Constant:i16<5>, Constant:i64<5>
Combining: t27: i32 = truncate t26
Replacing.2 t16: v8i16 = insert_vector_elt t13, Constant:i16<5>, Constant:i64<5>
With: t13: v8i16 = insert_vector_elt t11, t3, Constant:i64<4>
...
Optimized lowered selection DAG: %bb.0 'bar:entry'
SelectionDAG has 18 nodes:
t0: ch,glue = EntryToken
t2: i32,ch = CopyFromReg t0, Register:i32 %0
t3: i16 = truncate t2
t35: v8i16 = BUILD_VECTOR undef:i16, undef:i16, undef:i16, Constant:i16<3>, t3, poison:i16, poison:i16, poison:i16
t23: i128 = bitcast t35
t26: i128 = srl t23, Constant:i8<48>
t27: i32 = truncate t26
t5: i64,ch = CopyFromReg t0, Register:i64 %1
t30: ch = store<(store (s32) into %ir.p)> t0, t27, t5, undef:i64
t32: ch = X86ISD::RET_GLUE t30, TargetConstant:i32<0>
...
```
The above looks wrong!
Before the DAG combine rewrites the bitcast is casting a vector without poisoned elements into an i128, but in the optimized selection DAG the bitcast is casting a vector with poisoned elements into i128 making the result poison. So the result of the bitcast is now posion.
I suspect TargetLowering::SimplifyDemandedBits/SimplifyDemandedVectorElts somehow is to blame for this.
When dealing with BITCAST in SimplifyDemandedBits it may call SimplifyDemandedVectorElts. We need to make sure that all smaller source elements mapping to a larger element are demanded when looking at a bitcast from 'small element' src vector to a 'large element' vector.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138526] [clang] Warning for comparing `char8_t` to `char32_t`
Issue
138526
Summary
[clang] Warning for comparing `char8_t` to `char32_t`
Labels
clang
Assignees
Reporter
Eisenwave
Consider the following code:
```cpp
bool contains_oe(std::u8string_view str) {
for (char8_t c : str)
if (c == U'ö') // comparison always fails
return true;
return false;
}
```
If `str` is a correctly encoded UTF-8 string, the comparison always fails because no UTF-8 code unit can be `0x6F`, and `ö` is U+00F6. Comparing `charN_t` with different `N` is virtually always a bug, or could have just as well been written using a different type of literal. Comparing these types is not going to give meaningful results except for U+007F and below, and even then, it's unclear why you wouldn't use the proper type.
I've floated the idea of deprecating this behavior in the C++ standard in a number of places, and it was received positively. StackOverflow users also suggested getting rid of it here: https://stackoverflow.com/q/79604433/5740428
**In the meantime, it would be useful to have a warning when `charN_t` is converted to a different Unicode character type.** This warning should be triggered for any implicit conversion, not just as part of a comparison because the same bug can be produced like:
```cpp
bool contains_char(std::u8string_view str, char8_t c);
// ...
contains_char(U'ö');
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138560] [Offload] regression on sm_60
Issue 138560 Summary [Offload] regression on sm_60 Labels new issue Assignees jhuber6 Reporter ye-luo I saw a regression on `sm_60` caused by #122781 after the merge I got ``` fatal error: error in backend: PTX does not support "atomic" for orderings different than"NotAtomic" or "Monotonic" for sm_60 or older, but order is: "seq_cst". ``` on the develop, error becomes. ``` fatal error: error in backend: PTX does not support "atomic" for orderings different than"NotAtomic" or "Monotonic" for sm_60 or older, but order is: "acquire". ``` reproducer, code https://github.com/TApplencourt/OvO/blob/master/test_src/cpp/hierarchical_parallelism/memcopy-complex_double/target_teams_distribute_parallel_for.cpp ``` clang++ -fopenmp --offload-arch=sm_60 target_teams_distribute_parallel_for.cpp ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138596] Attributes appertaining to inner classes of class template specializations are duplicated
Issue
138596
Summary
Attributes appertaining to inner classes of class template specializations are duplicated
Labels
new issue
Assignees
Reporter
katzdm
Given the following:
```cpp
template
struct X {
struct [[deprecated]] Inner { };
[[deprecated]] static void fn() { };
};
int main() {
X::Inner d;
X::fn();
}
```
([Godbolt link w/ AST](https://godbolt.org/z/PTafvec6q))
Two duplicate `DeprecatedAttr` nodes are attached to the `ClassTemplateSpecializationDecl` corresponding to `X::Inner`. This can be observed for attributes whose `Attr.td` entry has both `Clone` and `MeaningfulToClassTemplateSpecialization` equal to `1`.
I believe that both `sema::instantiateTemplateAttribute` and `sema::instantiateTemplateAttributeForDecl` are being invoked for each attribute.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138595] [MLIR] convert-linalg-to-parallel-loops doesn't seem to parallelize reductions
Issue
138595
Summary
[MLIR] convert-linalg-to-parallel-loops doesn't seem to parallelize reductions
Labels
Assignees
Reporter
brian-kelley
I have a project that uses MLIR to lower linalg/tensor code to scf/memref. Ideally the resulting code exposes all possible parallelism from the input operations. One of the passes I'm using is ``--convert-linalg-to-parallel-loops``, but it falls back to a sequential ``scf.for`` loop for reduction dimensions, instead of ``scf.parallel/scf.reduce``.
Below are a couple of simple examples (dot and matmul) that turn the reduction dimension into ``scf.for`` loops. To replicate, run them through ``mlir-opt --convert-linalg-to-parallel-loops``.
Is there another way to generate parallel loops from linalg ops that will keep reductions parallel? One alternative I tried is ``--convert-linalg-to-affine-loops --affine-parallelize``, but this also parallelizes over the non-reduction dimensions only (and it seems like the affine dialect can't express a parallel reduction anyway).
dot.mlir:
```
module {
func.func @dot(%arg0: memref, %arg1: memref) -> f64 {
%alloc = memref.alloc() {alignment = 64 : i64} : memref
linalg.dot ins(%arg0, %arg1 : memref, memref) outs(%alloc : memref)
%0 = memref.load %alloc[] : memref
return %0 : f64
}
}
```
result:
```
module {
func.func @dot(%arg0: memref, %arg1: memref) -> f64 {
%c1 = arith.constant 1 : index
%c0 = arith.constant 0 : index
%alloc = memref.alloc() {alignment = 64 : i64} : memref
%dim = memref.dim %arg0, %c0 : memref
scf.for %arg2 = %c0 to %dim step %c1 {
%1 = memref.load %arg0[%arg2] : memref
%2 = memref.load %arg1[%arg2] : memref
%3 = memref.load %alloc[] : memref
%4 = arith.mulf %1, %2 : f64
%5 = arith.addf %3, %4 : f64
memref.store %5, %alloc[] : memref
}
%0 = memref.load %alloc[] : memref
return %0 : f64
}
}
```
matmul.mlir:
```
module {
func.func @dot(%arg0: memref<64x64xf64>, %arg1: memref<64x64xf64>) -> memref<64x64xf64> {
%alloc = memref.alloc() {alignment = 64 : i64} : memref<64x64xf64>
linalg.matmul ins(%arg0, %arg1 : memref<64x64xf64>, memref<64x64xf64>) outs(%alloc : memref<64x64xf64>)
return %alloc : memref<64x64xf64>
}
}
```
result:
```
module {
func.func @dot(%arg0: memref<64x64xf64>, %arg1: memref<64x64xf64>) -> memref<64x64xf64> {
%c1 = arith.constant 1 : index
%c64 = arith.constant 64 : index
%c0 = arith.constant 0 : index
%alloc = memref.alloc() {alignment = 64 : i64} : memref<64x64xf64>
scf.parallel (%arg2, %arg3) = (%c0, %c0) to (%c64, %c64) step (%c1, %c1) {
scf.for %arg4 = %c0 to %c64 step %c1 {
%0 = memref.load %arg0[%arg2, %arg4] : memref<64x64xf64>
%1 = memref.load %arg1[%arg4, %arg3] : memref<64x64xf64>
%2 = memref.load %alloc[%arg2, %arg3] : memref<64x64xf64>
%3 = arith.mulf %0, %1 : f64
%4 = arith.addf %2, %3 : f64
memref.store %4, %alloc[%arg2, %arg3] : memref<64x64xf64>
}
scf.reduce
}
return %alloc : memref<64x64xf64>
}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138566] Different behavior for comparison of integer comparison
Issue
138566
Summary
Different behavior for comparison of integer comparison
Labels
new issue
Assignees
Reporter
StefanoD
clang-version: 20.1.0
compiler flags: -Wall -O1 -Wextra -Wshadow -Weffc++ -Wno-long-long -pedantic -pedantic-errors -std=c++14
When two variables are multiplied, which leads to integer promotion and the result is not stored into a variable, following example [compiles without problems](https://godbolt.org/z/69v43z9nx):
```cpp
#include
bool square_less_than_method_A(uint16_t a, uint64_t b) {
// a * a does integer promotion
return (a * a < b);
}
int main(int, char**) {
return 0;
}
```
Assigning the product to a variable, results in a [compile error](https://godbolt.org/z/sMso378va):
```cpp
#include
bool square_less_than_method_B(uint16_t a, uint64_t b) {
const auto a_squared = a * a;
return a_squared < b;
}
int main(int, char**) {
return 0;
}
```
```
:5:22: warning: comparison of integers of different signs: 'const int' and 'uint64_t' (aka 'unsigned long') [-Wsign-compare]
5 | return a_squared < b;
| ~ ^ ~
```
The second example should also compile as `a*a` is always positive. So, I get here a false-positive warning.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138570] [clang][PAC] add support for authenticated-null-values ptrauth option
Issue 138570 Summary [clang][PAC] add support for authenticated-null-values ptrauth option Labels clang Assignees Reporter ojhunt ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138571] [runtimes?][PAC] harden unwinding
Issue 138571 Summary [runtimes?][PAC] harden unwinding Labels new issue Assignees Reporter ojhunt This requires changes to: * compilerrt * libc++abi * libunwind * _Maybe_ libc++ (need to verify) This is blocked on #136828 #138570 #136828 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138573] [mlir][TableGen] Add ability to mark builders etc. deprecated
Issue 138573 Summary [mlir][TableGen] Add ability to mark builders etc. deprecated Labels mlir Assignees Reporter krzysz00 It'd be nice to have some mechanism - maybe a `bit deprecated = 0;` in `AttrOrTypeBuilder` and `OpBuilder` that'd cause the tablegen code to emit a `[[deprecated]]` on the method in question, so that we can put up compiler warnings ahead of our intent to remove something ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138558] [C++20 modules]
Issue
138558
Summary
[C++20 modules]
Labels
new issue
Assignees
Reporter
bangerth
(This is an outgrowth of my work discussed in #127561 and related to https://github.com/dealii/dealii/issues/18071. @ChuanqiXu9: FYI)
The collection of module partition units below produces a bunch of errors of the following kind:
```
/usr/bin/clang++-20 -std=c++20 -stdlib=libc++ -MD -MT CMakeFiles/test.dir/b.cc.o -MF CMakeFiles/test.dir/b.cc.o.d @CMakeFiles/test.dir/b.cc.o.modmap -o CMakeFiles/test.dir/b.cc.o -c /home/bangerth/tmp/bug/b.cc
In module 'test:A' imported from /home/bangerth/tmp/bug/b.cc:6:
/usr/include/c++/v1/__random/mersenne_twister_engine.h:223:15: error: cannot befriend target of using declaration
223 | friend bool operator==(
| ^
/home/bangerth/tmp/bug/b.cc:12:16: note: in instantiation of template class 'std::mersenne_twister_engine' requested here
12 | std::mt19937 x1, x2;
| ^
/usr/include/c++/v1/__random/mersenne_twister_engine.h:764:1: note: target of using declaration
764 | operator==(const mersenne_twister_engine<_UInt, _Wp, _Np, _Mp, _Rp, _Ap, _Up, _Dp, _Sp, _Bp, _Tp, _Cp, _Lp, _Fp>& __x,
| ^
/home/bangerth/tmp/bug/std.ccm:23:14: note: using declaration
23 | using std::operator==;
| ^
In module 'test:A' imported from /home/bangerth/tmp/bug/b.cc:6:
/usr/include/c++/v1/__random/mersenne_twister_engine.h:241:15: error: cannot befriend target of using declaration
241 | friend bool operator!=(
| ^
/usr/include/c++/v1/__random/mersenne_twister_engine.h:807:1: note: target of using declaration
807 | operator!=(const mersenne_twister_engine<_UInt, _Wp, _Np, _Mp, _Rp, _Ap, _Up, _Dp, _Sp, _Bp, _Tp, _Cp, _Lp, _Fp>& __x,
| ^
/home/bangerth/tmp/bug/std.ccm:24:14: note: using declaration
24 | using std::operator!=;
| ^
[...]
```
I can't see any good reason for this -- it seems like a bug to me.
Here are the relevant files:
```
// a.ccm
module;
#include
export module test:A;
export {}
```
```
// std.ccm
module;
#include
#include
export module test:std;
export {
namespace std {
using std::mt19937;
using std::mutex;
using std::operator==;
using std::operator!=;
// Would ordinarily contain much more stuff here...
} // namespace std
#if defined(_LIBCPP_VERSION) // For CLang's support library
_LIBCPP_BEGIN_NAMESPACE_STD
using std::operator==;
using std::operator!=;
_LIBCPP_END_NAMESPACE_STD
#endif
} // export
```
```
// b.cc
module;
module test:B;
import :std;
import :A;
bool test()
{
static std::mutex rand_mutex; // Necessary, for unclear reasons
std::mt19937 x1, x2;
return (x1 == x2) && (x1 != x2);
}
```
```
# CMakeLists.txt
cmake_minimum_required(VERSION 3.28 FATAL_ERROR)
project(test LANGUAGES CXX)
add_library(test)
target_compile_features(test PUBLIC cxx_std_20)
target_sources(test PUBLIC
FILE_SET CXX_MODULES
FILES
std.ccm
a.ccm
b.cc)
```
Here are a couple of observations:
* The errors go away if I remove the `#include ` from `a.ccm`. Because `a.ccm` does not actually export anything, the presence of `` does not strike me as wrong. In my original testcase, I cannot remove it because it is transitively `#include`d by something else I actually need in that file -- `a.ccm` wraps an external library of which one of the headers happens to `#include `.
* The `:std` partition also exports the symbols in `_LIBCPP_BEGIN_NAMESPACE_STD`. This is needed to avoid other errors, and is something that @davidstone had already realized in https://github.com/davidstone/std_module/blob/d121f1701884953c9ca468b159b530556e2475a3/source/std_module.cpp, for example. If I remove these lines, the error goes away, but I get many more errors in other places in return (just not for this minimal testcase).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138581] ThreadSanitizer doesn't work with memory overcommit disabled
Issue 138581 Summary ThreadSanitizer doesn't work with memory overcommit disabled Labels new issue Assignees Reporter zackw On Linux, if memory overcommit has been disabled (`sysctl -w vm.overcommit_memory=2`), all programs compiled with `-fsanitize=thread` crash on startup with an error message... ``` ==363640==ERROR: ThreadSanitizer failed to allocate 0x2000 (35184372088832) bytes at address 1000 (errno: 12) FATAL: ThreadSanitizer can not mmap the shadow memory FATAL: Make sure to compile with -fPIE and to link with -pie. ``` ... that indicates ThreadSanitizer attempted to allocate *32 terabytes* of RAM. That's not a reasonable amount of memory to expect a developer workstation to have. Please change ThreadSanitizer so that it only allocates shadow memory proportional to the amount of RAM that the program actually uses. You can probably use `MAP_NORESERVE` to allocate a range of *address space* without also allocating RAM. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138532] CUDA offload fails to verify devices > SM90
Issue 138532 Summary CUDA offload fails to verify devices > SM90 Labels Assignees Reporter hummingtree The most likely reason is the line here: https://github.com/llvm/llvm-project/blob/f49ee00ec47f596269639987f5ea8755a358ca16/offload/plugins-nextgen/common/src/Utils/ELF.cpp#L79. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138533] [HLSL][SPIRV] Replace name mangling for resource types
Issue 138533 Summary [HLSL][SPIRV] Replace name mangling for resource types Labels new issue Assignees s-perron Reporter s-perron The SPIR-V currently relies on name mangling to be able to be able to get the correct resource for calls to `Intrinsic::spv_resource_handlefrombinding`. Our own name mangling was implemented including mangling the types of the resource being accessed. This is hard to maintain because the name for the mangled type has to be kept up-to-date. It might be better to rely on something else. In particular, we should try to rely on the name of the resource; however that will no longer be available. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138536] [LLDB] [GDB server] Host byte order incorrectly used for `g`, `G`, `p`, `P` packet types
Issue 138536 Summary [LLDB] [GDB server] Host byte order incorrectly used for `g`, `G`, `p`, `P` packet types Labels new issue Assignees Reporter whitequark The [GDB server protocol specification](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Packets.html#Packets) is very clear on the topic: > ‘g’ > Read general registers. > > Reply: > > ‘XX…’ > Each byte of register data is described by two hex digits. The bytes with the register are transmitted in **target byte order**. The size of each register and their position within the ‘g’ packet are determined by the target description (see [Target Descriptions](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Target-Descriptions.html#Target-Descriptions)); in the absence of a target description, this is done using code internal to GDB; typically this is some customary register layout for the architecture in question. However, LLDB incorrectly uses the **debugger host byte order** (which may not be the same as the target byte order): https://github.com/llvm/llvm-project/blob/f33821628d0e03f5389e1f4339b4d10f6a8883b5/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L3566-L3578 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 138584] [lld] Unsorted loadable program headers with `-Ttext=` argument
Issue
138584
Summary
[lld] Unsorted loadable program headers with `-Ttext=` argument
Labels
Assignees
Reporter
pskrgag
ELF spec say that program headers must be sorted by `p_vaddr`
> Loadable segment entries in the program header table appear in ascending order,
> sorted on the p_vaddr member
However it does not work if `-Ttext` argument is used.
Consider following example:
```c
int main(void)
{
while (1);
}
```
```bash
~/Documents/compiler_ws/lld
paskripkin > ~/Documents/git/llvm-project/build/bin/ld.lld -e main -Ttext=0x80 test.o -o a.out
~/Documents/compiler_ws/lld
paskripkin > llvm-readelf -l a.out
Elf file type is EXEC (Executable file)
Entry point 0x80
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x40 0x00200040 0x00200040 0x000118 0x000118 R 0x8
LOAD 0x00 0x0020 0x0020 0x000158 0x000158 R 0x1000
LOAD 0x001000 0x0080 0x0080 0x0d 0x0d R E 0x1000
LOAD 0x001010 0x00801010 0x00801010 0x3c 0x3c R 0x1000
GNU_STACK 0x00 0x 0x 0x00 0x00 RW 0x0
Section to Segment mapping:
Segment Sections...
00
01
02 .text
03 .eh_frame
04
None .comment .symtab .shstrtab .strtab
```
Note that first loadable segment has a `p_vaddr` less than the second one. (still reproduces on current master c50cba6275271fba69be661b9ec0665b2be88dbc).
## Sort of analysis
The first loadable segment is the one that contains ELF header and program headers. It's added in `Writer::createPhdrs`.
```cpp
// Add the headers. We will remove them if they don't fit.
// In the other partitions the headers are ordinary sections, so they don't
// need to be added here.
if (isMain) {
load = addHdr(PT_LOAD, flags);
load->add(ctx.out.elfHeader.get());
load->add(ctx.out.programHeaders.get());
}
```
In normal case it gets merged into some of other segments because of the following code
```cpp
bool sameLMARegion =
load && !sec->lmaExpr && sec->lmaRegion == load->firstSec->lmaRegion;
if (load && sec != relroEnd &&
sec->memRegion == load->firstSec->memRegion &&
(sameLMARegion || load->lastSec == ctx.out.programHeaders.get()) &&
(ctx.script->hasSectionsCommand || sec->type == SHT_NOBITS ||
load->lastSec->type != SHT_NOBITS)) {
load->p_flags |= newFlags;
} else {
load = addHdr(PT_LOAD, newFlags);
flags = newFlags;
}
```
However if `-Ttext` is specified, predicate above may fail and new segment will be inserted. Then during `LinkerScript::assignAddresses`, first `PT_LOAD` segment gets assigned to `ctx.target->getImageBase()`, which may be far from the base of `text` (IIUC lld starts calculating from the base passed in `-T`).
## Note
This is not a synthetic example. It was observed in real life with very strict elf loader.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
