[llvm-bugs] [Bug 145665] `bugprone-nondeterministic-pointer-iteration-order` reported with custom comparator
Issue
145665
Summary
`bugprone-nondeterministic-pointer-iteration-order` reported with custom comparator
Labels
clang-tidy,
false-positive
Assignees
Reporter
firewave
```cpp
#include
#include
struct S
{
int i() const;
};
void f()
{
std::vector v;
std::sort(v.begin(), v.end(), [](const S* s1, const S* s2){
return s1->i() > s2->i();
});
}
```
```
:12:5: warning: sorting pointers is nondeterministic [bugprone-nondeterministic-pointer-iteration-order]
12 | std::sort(v.begin(), v.end(), [](const S* s1, const S* s2){
| ^~~
13 | return s1->i() > s2->i();
| ~
14 | });
```
https://godbolt.org/z/xjYe63rY6
This is only reported with libc++.
The warning should not be reported if a custom compare function is provided.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145673] clang-format for obj-c lines up colons inside @selector
Issue
145673
Summary
clang-format for obj-c lines up colons inside @selector
Labels
clang-format
Assignees
Reporter
zmodem
Consider:
```
$ cat /tmp/a.mm
- (void)setSearchBarText:(NSString*)text {
_searchBar.text = text;
if ([_searchBar.delegate respondsToSelector:@selector(searchBar:textDidChange:)]) {
[_searchBar.delegate searchBar:_searchBar textDidChange:text];
}
}
$ build/bin/clang-format /tmp/a.mm
- (void)setSearchBarText:(NSString *)text {
_searchBar.text = text;
if ([_searchBar.delegate respondsToSelector:@selector(searchBar:
textDidChange:)]) {
[_searchBar.delegate searchBar:_searchBar textDidChange:text];
}
}
```
To break the long line, clang-format aligned `searchBar:` and `textDidChange:` on the colons, but breaking up the `@selector(searchBar:textDidChange:)` argument doesn't seem great. Perhaps it would have been better to break the line before `respondsToSelector:` instead, something like:
```
- (void)setSearchBarText:(NSString*)text {
_searchBar.text = text;
if ([_searchBar.delegate
respondsToSelector:@selector(searchBar:textDidChange:)]) {
[_searchBar.delegate searchBar:_searchBar textDidChange:text];
}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145667] `bugprone-nondeterministic-pointer-iteration-order` is only reported with libc++
Issue
145667
Summary
`bugprone-nondeterministic-pointer-iteration-order` is only reported with libc++
Labels
clang-tidy
Assignees
Reporter
firewave
```
#include
#include
void f()
{
std::vector v;
std::sort(v.begin(), v.end());
}
```
```
:6:23: error: unknown type name 'S' [clang-diagnostic-error]
6 | std::vector v;
| ^
```
The warning is only shown when using libc++.
libstdc++: https://godbolt.org/z/543cGGnqq
libc++: https://godbolt.org/z/1Th935cvz
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145712] counted_by cannot be used with C23 attribute syntax
Issue
145712
Summary
counted_by cannot be used with C23 attribute syntax
Labels
new issue
Assignees
Reporter
tavianator
[The docs](https://clang.llvm.org/docs/AttributeReference.html#counted-by-counted-by-or-null-sized-by-sized-by-or-null) claim that `counted_by` has a C23 attribute syntax equivalent of `[[clang::counted_by(...)]]`. However:
```console
tavianator@graphene$ cat foo.c
struct foo {
int n;
int a[] [[clang::counted_by(n)]];
};
struct bar {
int n;
int a[] __attribute__((counted_by(n)));
};
tavianator@graphene$ clang -fsyntax-only foo.c
foo.c:3:12: error: 'counted_by' attribute cannot be applied to types
3 | int a[] [[clang::counted_by(n)]];
| ^
1 error generated.
tavianator@graphene$ clang -v
clang version 20.1.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/15.1.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145676] [C++20] [Modules] [ABI] The linkage of in-class defaulted function
Issue
145676
Summary
[C++20] [Modules] [ABI] The linkage of in-class defaulted function
Labels
new issue
Assignees
Reporter
ChuanqiXu9
e.g.,
```
export module a;
export class A {
public:
A() = default;
~A() = default;
};
```
I believe we should generate `A::A()` and `A::~A()` in current TU instead of treating them as inline now.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145695] [mlir] prop-dict printout sometimes starts with `<{`, but sometimes with `< {`
Issue
145695
Summary
[mlir] prop-dict printout sometimes starts with `<{`, but sometimes with `< {`
Labels
mlir
Assignees
Reporter
peledins-zimperium
This happens, because:
```
void OpState::genericPrintProperties(OpAsmPrinter &p, Attribute properties,
ArrayRef elidedProps) {
...
if (dictAttr && !elidedProps.empty()) {
...
if (atLeastOneAttr) {
p << "<";
p.printOptionalAttrDict(dictAttr.getValue(), elidedProps); // "< {" - has space
p << ">";
}
} else {
p << "<" << properties << ">"; // "<{" - no space
}
...
```
This depends on whether there are ellided properties being specified in printout or not:
In "< {" case the end result is:
```
AsmPrinter::Impl::printOptionalAttrDict
...
// Otherwise, print them all out in braces.
os << " {"; THE SPACE IS COMING FROM HERE
interleaveComma(filteredAttrs,
[&](NamedAttribute attr) { printNamedAttribute(attr); });
os << '}';
```
But in other case
```
void AsmPrinter::Impl::printAttributeImpl(Attribute attr,
AttrTypeElision typeElision) {
if (!isa(attr.getDialect())) {
...
} else if (auto dictAttr = llvm::dyn_cast(attr)) {
os << '{';
interleaveComma(dictAttr.getValue(),
[&](NamedAttribute attr) { printNamedAttribute(attr); });
os << '}';
```
It would be great to be consistent.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145705] Request Commit Access For mikolaj-pirog
Issue 145705 Summary Request Commit Access For mikolaj-pirog Labels infra:commit-access-request Assignees Reporter mikolaj-pirog I'm requesting commit access in order to be able to merge my PRs after approval from codeowners and to be able to add reviewers in the dedicated field on my own. I'm compiler engineer at Intel, focusing on X86 codegen ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145658] [Clang] Implement P2843R3 - Preprocessing is never undefined
Issue
145658
Summary
[Clang] Implement P2843R3 - Preprocessing is never undefined
Labels
clang,
c++26
Assignees
Reporter
cor3ntin
Here are some test cases for this paper.
The limitations on line numbers may be a bit restrictive, show we ask WG21 to make that implementation defined?
We currently do not diagnose directives in arguments of function macros, so this should
probably comes with an opt-out mechanism
```cpp
// [cpp.include]: nothing to do
#define FOO invalid
#include FOO
// expected-error@-1 {{expected "FILENAME" or }}
// [cpp.cond]
#define DEFINED defined
#if DEFINED(bar) // Should be an error
#endif
// [cpp.replace.general]
#define FUNCTION_MACRO(...)
FUNCTION_MACRO(
#if 0 // should diagnose
#endif
)
// [cpp.stringize]: nothing to do
#define STR(x) # x
const char* a = STR(\o{999});
// [cpp.concat]: nothing to do
#define CONCAT(A, B) A ## B
CONCAT(=, >)
// expected-error@-1 {{pasting formed '=>', an invalid preprocessing token}}
// [cpp.predefined]
#undef defined
// expected-error@-1 {{error: 'defined' cannot be used as a macro name}}
#undef __DATE__
// expected-warning@-1 {{undefining builtin macro}}
// should be turned into an error by default
// [cpp.line]
#line 0 // should diagnose
#line -1
#line 2147483647
#line 2147483648 // should diagnose ?
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145680] [clang-tidy] False positives bugprone-dynamic-static-initializers
Issue
145680
Summary
[clang-tidy] False positives bugprone-dynamic-static-initializers
Labels
clang-tidy
Assignees
Reporter
carlosgalvezp
I believe the check warns incorrectly in the following cases:
```cpp
#include
template
constexpr T kMin{std::numeric_limits::min()};
template
struct X
{
static constexpr int xn{n};
};
```
```bash
$ clang-tidy --checks=-*,bugprone-dynamic-static-initializers foo.hpp -- -fno-threadsafe-statics
589 warnings generated.
/tmp/foo.hpp:4:13: warning: static variable 'kMin' may be dynamically initialized in this header file [bugprone-dynamic-static-initializers]
4 | constexpr T kMin{std::numeric_limits::min()};
| ^
/tmp/foo.hpp:9:24: warning: static variable 'xn' may be dynamically initialized in this header file [bugprone-dynamic-static-initializers]
9 | static constexpr int xn{n};
|^
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145703] Precommit CI failures
Issue
145703
Summary
Precommit CI failures
Labels
infrastructure
Assignees
Reporter
AaronBallman
```
[6099/6110] Running clang_tools regression tests
llvm-lit.py: C:\_work\llvm-project\llvm-project\llvm\utils\lit\lit\llvm\config.py:57: note: using lit tools: C:\Program Files\Git\usr\bin
llvm-lit.py: C:\_work\llvm-project\llvm-project\llvm\utils\lit\lit\llvm\config.py:520: note: using clang: c:\_work\llvm-project\llvm-project\build\bin\clang.exe
llvm-lit.py: C:\_work\llvm-project\llvm-project\llvm\utils\lit\lit\llvm\config.py:312: fatal: Couldn't find the include dir for Clang ('c:\_work\llvm-project\llvm-project\build\bin\clang.exe')
c:\_work\llvm-project\llvm-project\build\bin\clang.exe
[6101/6110] Linking CXX executable bin\obj2yaml.exe
FAILED: tools/clang/tools/extra/CMakeFiles/check-clang-tools
cmd.exe /C "cd /D C:\_work\llvm-project\llvm-project\build\tools\clang\tools\extra && C:\Python39\python.exe C:/_work/llvm-project/llvm-project/build/./bin/llvm-lit.py -v --xunit-xml-output C:/_work/llvm-project/llvm-project/build/test-results.xml --use-unique-output-file-name --timeout=1200 --time-tests C:/_work/llvm-project/llvm-project/build/tools/clang/tools/extra/include-cleaner/test C:/_work/llvm-project/llvm-project/build/tools/clang/tools/extra/clangd/test/../unittests C:/_work/llvm-project/llvm-project/build/tools/clang/tools/extra/clangd/test C:/_work/llvm-project/llvm-project/build/tools/clang/tools/extra/test"
[6103/6110] Linking CXX executable bin\clang.exe
```
It looks like we try to run the clang-tools-extra regression tests which seem to be looking for clang.exe which isn't yet built.
Some examples of this in the wild include:
https://github.com/llvm/llvm-project/actions/runs/15875229617/job/44761115591?pr=145679
https://github.com/llvm/llvm-project/actions/runs/15860875108/job/44717506023?pr=143424
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145713] CI tests do not detect `clang_cl` tests that would break on non-Windows test hosts
Issue 145713 Summary CI tests do not detect `clang_cl` tests that would break on non-Windows test hosts Labels new issue Assignees Reporter sivadeilra See this thread: https://github.com/llvm/llvm-project/pull/145565#issuecomment-3004861443 This PR added new `llvm-lit` tests for `clang-cl`. The PR CI jobs were green, but after merging, it was found that this broke Solaris buildbot. This issue is for finding a way to detect this problem during PR CI jobs, so that breaks can be found before merging. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145821] [SPIR-V] Unimplemented implicit down-casts from bitcasted loads
Issue
145821
Summary
[SPIR-V] Unimplemented implicit down-casts from bitcasted loads
Labels
new issue
Assignees
Reporter
winocm
This is a minimal test case that demonstrates the issue:
```llvm
; RUN: llc -verify-machineinstrs -O0 -mtriple=spirv-vulkan1.3-unknown %s -o - | FileCheck %s
@bar = external addrspace(2) externally_initialized global i32
define void @foo() {
%load = load <4 x i8>, ptr addrspace(2) @bar, align 4
ret void
}
```
Loads (and probably stores) that are effectively the same size as the target variable require intermediate bitcasts.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145847] [lldb] std::unordered_map const reference presentation is different from non-const reference
Issue
145847
Summary
[lldb] std::unordered_map const reference presentation is different from non-const reference
Labels
Assignees
Reporter
nd-work
To reproduce, debug the following on macOS:
```
#include
int main() {
std::unordered_map m;
m[1] = 2;
std::unordered_map& ref = m;
const std::unordered_map& const_ref = m;
return 0; // break
}
```
When breakpoint is reached, print `ref` and `const_ref`.
Expected: `const_ref` is printed in the same way as `ref`.
Actual: they are printed differently:
```
> clang++ -g main.cpp
> lldb a.out
(lldb) target create "a.out"
Current executable set to '/path/to/a.out' (arm64).
(lldb) version
lldb version 21.0.0git (g...@github.com:llvm/llvm-project.git revision c3b160bcaa7dd5b5564ae8868fb33e7ba6169283)
clang revision c3b160bcaa7dd5b5564ae8868fb33e7ba6169283
llvm revision c3b160bcaa7dd5b5564ae8868fb33e7ba6169283
(lldb) b main.cpp:8
Breakpoint 1: where = a.out`main + 88 at main.cpp:8:3, address = 0x00010540
(lldb) run
Process 87854 launched: '/path/to/a.out' (arm64)
Process 87854 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010540 a.out`main at main.cpp:8:3
5 m[1] = 2;
6 std::unordered_map& ref = m;
7 const std::unordered_map& const_ref = m;
-> 8 return 0; //break
9 }
(lldb) frame var ref
(std::unordered_map &) ref = 0x00016fdff040 size=1: {
[0] = (first = 1, second = 2)
}
(lldb) frame var const_ref
(const std::unordered_map &) const_ref = 0x00016fdff040 size=1: {
[0] = {
__cc_ = (first = 1, second = 2)
}
}
(lldb)
```
It seems to happen because LibCxx.cpp `isStdTemplate()` doesn't handle modifiers.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145818] [HLSL][RootSignature] Allow for error during Root Signature parsing
Issue 145818 Summary [HLSL][RootSignature] Allow for error during Root Signature parsing Labels HLSL Assignees inbelic Reporter inbelic At the moment, the `HLSLRootSignatureParser` will early exit when it encounters it's first error. To be more in line with Clang error parsing, and to hopefully reduce the number of compile cycles for users, we can modify the parser to continue looking for parsing errors even after we encounter the first one. For this to be ready for refinement, we should answer the question of what granularity we can do so. It seems fairly straightforward at the granularity of a `RootElement` (RootConstants, CBV, StaticSampler, etc.), but we can see how complex it might be to make that granularity smaller. AC: - [ ] `HLSLRootSignatureParser` is updated to allow for reporting multiple parsing errors at a given granularity ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145819] [HLSL][RootSignature] Retain `SourceLocation` of `RootElement` for use in Diags with `SemaHLSL`
Issue 145819 Summary [HLSL][RootSignature] Retain `SourceLocation` of `RootElement` for use in Diags with `SemaHLSL` Labels HLSL Assignees inbelic Reporter inbelic At the moment, when we report diagnostics from `SemaHLSL` we only provide the source location of the attr. This allows for significantly less helpful diagnostics (for eg. reporting resource range overlaps). This issue tracks implementing a way to retain the source location of a root element when it is parsed, so that we can output its `SourceLocation` in the diagnostics produce during semantic analysis. Potential solutions: - [ ] Using a `DenseMap` to point from a `RootElement` to its `SourceLocation` - [ ] Creating a wrapper `clang::hlsl::RootElement` struct that wraps the `llvm::hlsl::rootsig::RootElement` equivalent, that will hold all additional diagnostic data that wouldn't be available to `llvm::hlsl:rootsig::RootElement`. A potential solution should be listed as a proposed solution before it is ready for refinement. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145815] [HLSL][RootSignature] Move `D3D12` enums defined in `HLSLRootSignature` to `BinaryFormat/DXContainer`
Issue 145815 Summary [HLSL][RootSignature] Move `D3D12` enums defined in `HLSLRootSignature` to `BinaryFormat/DXContainer` Labels HLSL Assignees inbelic Reporter inbelic At the moment we currently have many of the same enums defined for both the frontend and backend of handling root signatures. We can move many of these from where they are currently defined in `HLSLRootSignature.h` to one location in `BinaryFormat/DXContainer.h` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145814] [HLSL][RootSignature] Fix formatting of puncuator Tokens in `LexHLSL`
Issue 145814 Summary [HLSL][RootSignature] Fix formatting of puncuator Tokens in `LexHLSL` Labels HLSL Assignees inbelic Reporter inbelic There is a bug in the diagnostic output of `ParseHLSLRootSignature` when outputting a punctuator. Instead of outputting the string literal of the token `','` it instead will treat it as an integer and output the ascii value. Proposed solution: Update the following switch statement to have a separate macro for `PUNCUATOR` that will output a string literal of the character as opposed to just the character. https://github.com/llvm/llvm-project/blob/b413bea4355e51e3f3ff248b7d62b4d5d712c743/clang/include/clang/Lex/LexHLSLRootSignature.h#L46-L56 For instance: https://godbolt.org/z/vbY717qMh ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145801] [Clang] Mixed use of VLAs and alloca leads to miscompilation (early pop of alloca memory)
Issue
145801
Summary
[Clang] Mixed use of VLAs and alloca leads to miscompilation (early pop of alloca memory)
Labels
clang
Assignees
Reporter
kkofler
In this (minimized, not linkable, use `clang -O2 -S allocatest.c` and look at the output to test) testcase:
```c
#include
struct nlopt;
extern int n;
struct nlopt *create(void);
void f(struct nlopt *opt, double *x, void *userdata);
void solve(struct nlopt *opt);
int main(void)
{
struct nlopt *opt = create();
int i;
{
double x[n];
for (i = 0; i < n; i++) {
void *p = alloca(8);
f(opt, x, p);
}
}
solve(opt);
return 0;
}
```
the `alloca` needs to live until the end of the function, but (as evidenced by the assembly output), Clang actually emits code to restore `rsp` to its value before the VLA creation at the point where the VLA goes out of scope, and that also ends up destroying the arrays from `alloca`.
In the real (much longer) code, the `solve` function (actually called `nlopt_optimize`) ends up using the pointers that were recorded in the `opt` structure by the function `f` (actually called `nlopt_add_inequality_constraint`), but due to the early pop, they will have been overwritten, leading to a crash.
I can reproduce this both with the latest clang version 18.1.8 and with the ancient clang version 13.0.1, so this is a longstanding bug.
GCC gets this right: `gcc -O2 -S allocatest.c` shows that `rsp` is **not** restored until after `solve` is called (so the lifetime of the VLA also has to be extended, but there is not really a way around that in this case), and in fact, the real program also does not crash when compiled with GCC as it does when compiled with Clang.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145820] [HLSL][RootSignature] `HLSLRootSignatureParser` should initialize default `flags` values based on version.
Issue 145820 Summary [HLSL][RootSignature] `HLSLRootSignatureParser` should initialize default `flags` values based on version. Labels HLSL Assignees inbelic Reporter inbelic When adding `RootSignatureVersion` to the compiler options, it was forgotten to also update `setDefaultFlags` [here](https://github.com/llvm/llvm-project/blob/b413bea4355e51e3f3ff248b7d62b4d5d712c743/llvm/include/llvm/Frontend/HLSL/HLSLRootSignature.h#L172), to set the default values of `RootDescriptorFlags` and `DescriptorRangeFlags` dependent on the version. This requires an update to `RootSignatureParser` to be given the version and initialize accordingly. AC: - [ ] Update `RootSignatureParser` to have a `Version` member - [ ] Use this version member to correctly invoke `setDefaultFlags` - [ ] Update `setDefaultFlags` to initialize the flags correctly from the updated specs ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145651] [clang-tidy] `bugprone-signed-char-misuse` gives false positives in C23 for enum with signed char type
Issue
145651
Summary
[clang-tidy] `bugprone-signed-char-misuse` gives false positives in C23 for enum with signed char type
Labels
clang-tidy
Assignees
Reporter
bjosv
When running `bugprone-signed-char-misuse` on C23 code that uses [enums](https://en.cppreference.com/w/c/language/enum.html
) with a fixed underlying type of `signed char` we get warnings.
```
enum e : signed char {
E_M128 = -128,
};
enum e state = E_M128;
```
A full example:
https://godbolt.org/z/vGTj966TY
The checker gets that the RHS EnumConstant is a `signed char` but don't use the fact that LHS is of type signed char, giving a warning.
The RHS seems to give the AST
`ImplicitCastExpr 'e_t':'enum e' `
but we have not found anything in the standard that motivates the warning and we believe it's a false positive.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145779] [clang][modules] Change --print-library-module-manifest-path to --print-std-module-manifest-path ??
Issue 145779 Summary [clang][modules] Change --print-library-module-manifest-path to --print-std-module-manifest-path ?? Labels clang Assignees Reporter evantorrie In #76451, @ChuanqiXu9 made [this suggestion](https://github.com/llvm/llvm-project/pull/76451#discussion_r1437330950_) ```suggestion def print_std_module_manifest_path : Flag<["-", "--"], "print-std-module-manifest-path">, ``` While the name of the variable (via the `def ...`) was changed, the actual text of the command line argument was left as `--print-library-module-manifest-path`. Has this ship sailed? Or is there still time to standardize this so that the option better reflects its semantics – which is to print only the C++ standard library modules manifest -- not "general" library module manifests as I understand it. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145752] [HLSL][DirectX] `firstbithigh` returns bit index from wrong side
Issue 145752 Summary [HLSL][DirectX] `firstbithigh` returns bit index from wrong side Labels HLSL Assignees Reporter V-FEXrt https://godbolt.org/z/1ahzc64a8 DXC returns `32 - firstbit(S)hi` instead of directly returning `firstbit(S)hi` like clang currently does. This test confirms it is intentional https://github.com/microsoft/DirectXShaderCompiler/blob/b390fb19adc5d7c23180eb470470411fce986910/tools/clang/test/HLSLFileCheck/hlsl/intrinsics/bitwise/firstbitHi.hlsl#L10 Without the inversion the result has the bit set from the wrong direction. This is a bug in the clang lowering that was caught by https://github.com/llvm/offload-test-suite/pull/210 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145763] Support for tanhf on aarch64 with a vectorized SVE implementation
Issue 145763 Summary Support for tanhf on aarch64 with a vectorized SVE implementation Labels new issue Assignees Reporter hiraditya Cloning https://github.com/openxla/xla/issues/24201 to bring it up with ARM folks. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145776] [Clang] Immediate-escalating expression attributed to wrong lambda
Issue
145776
Summary
[Clang] Immediate-escalating _expression_ attributed to wrong lambda
Labels
clang
Assignees
Reporter
katzdm
The following should be well-formed, but [clang diagnoses](https://godbolt.org/z/57xfWbE71):
```cpp
void runtime_only() { }
consteval void comptime_only() {}
void fn() {
[]() {
runtime_only();
[](){ (void) comptime_only; }();
}();
}
```
The _id-expression_ that names `comptime_only` is [immediate-escalating](https://eel.is/c++draft/expr.const#25.1). Clang currently attributes that _expression_ to the outer lambda, despite its occurrence within the inner lambda. It seems to me that this stems from the `ExpressionEvaluationContext` corresponding to the inner lambda [being popped](https://github.com/llvm/llvm-project/blob/0c359d747daa97197d17d2c48d7964d49f7f1b98/clang/lib/Sema/SemaLambda.cpp#L2173) _after_ the `FunctionScopeInfo` corresponding to the same has [already been popped](https://github.com/llvm/llvm-project/blob/0c359d747daa97197d17d2c48d7964d49f7f1b98/clang/lib/Sema/SemaLambda.cpp#L1978). Naively re-sequencing these operations appears to cause other problems (e.g., failing assertions related to ODR-uses in `ActOnFinishFunctionBody`).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145756] No CMake setting to trigger BlocksRuntime build
Issue 145756 Summary No CMake setting to trigger BlocksRuntime build Labels new issue Assignees Reporter eschaton I'm doing some embedded development for Cortex-M33 with `clang` and I'd like to use blocks in my code. However, I can't find any CMake settings/flags that would trigger BlocksRuntime to be built and installed alongside the builtins. I was expecting a flag like `COMPILER_RT_BUILD_BLOCKS`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145729] [DirectX] Support typedBufferLoad and Store for RWBuffer, RWBuffer
Issue 145729 Summary [DirectX] Support typedBufferLoad and Store for RWBuffer, RWBuffer Labels new issue Assignees farzonl Reporter spall HLSL's Buffer/RWBuffer can operate on a vector of two 64 bit integers, like so: https://hlsl.godbolt.org/z/Mevonvav8 The typedBufferLoad and Store dxil intrinsics (introduced in https://github.com/llvm/llvm-project/pull/104252 and https://github.com/llvm/llvm-project/pull/104253) should be taught to handle a vector of 2 64 bit integers. Support needs to be added for int64_t and uint64_t as well. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145485] [mlir][spirv] Incomplete handling of memory operands in CoopMatrix memory operations
Issue 145485 Summary [mlir][spirv] Incomplete handling of memory operands in CoopMatrix memory operations Labels mlir Assignees Reporter IgWod-IMG Creating primarily for tracking purposes. It seems that currently `CooperativeMatrixStore` and `CooperativeMatrixLoad` have an incomplete handling of `MakePointerAvailable` and `MakePointerVisible`. There are two issues: 1. The verification does not check that `NonPrivatePointer` is present if any of two aforementioned memory operands are used, but it is enforced by the spec. 2. Both memory operands (`MakePointerAvailable` and `MakePointerVisible`) expect the scope to be provided, but currently none of the memory operations accepts the scope. Relevant section of the spec: https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_memory_operands This was spotted when working on #145480. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145453] [clang] `pragma-comment.c` test fails when developer's GitHub handle is `dbartol`
Issue
145453
Summary
[clang] `pragma-comment.c` test fails when developer's GitHub handle is `dbartol`
Labels
clang
Assignees
Reporter
hideous-destructor
I've certainly had many encounters with tests that only fail on my machine, but this is the first time the test was specifically out to get me:
### To repro
```bash
llvm-lit -v ./clang/test/CodeGen/pragma-comment.c
```
### Actual result:
```
/Volumes/LocalData/Code/Public/bar/llvm-project/clang/test/CodeGen/pragma-comment.c:33:13: error: ELF-NOT: excluded string found in input
// ELF-NOT: bar
^
:16:55: note: found here
!6 = !{!"clang version 21.0.0git (https://github.com/dbartol/llvm-project 97e8266172533fe9deb701a0851b442298f0f011)"}
^~~
Input file:
Check file: /Volumes/LocalData/Code/Public/bar/llvm-project/clang/test/CodeGen/pragma-comment.c
```
### Expected result
Successful test
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145506] Missing warning if variable is used in else clause of if (type_t var = ...)
Issue
145506
Summary
Missing warning if variable is used in else clause of if (type_t var = ...)
Labels
new issue
Assignees
Reporter
Alcaro
```c++
int* get_something();
int* get_something_else();
int square() {
if (int* ptr1 = get_something())
return ptr1[0] * ptr1[0];
else if (int* ptr2 = get_something_else())
return ptr1[0] * ptr2[0]; // whoops, typoed!
else
return -1;
}
```
Expected: Compiler warning about how ptr1 is always null on the commented line. (Simplifying the example further returns an unused-variable warning for ptr2; that's not what I'm asking for.)
Actual: No output, just pretends ptr1[0] is 0 and optimizes accordingly. (Ideally, ptr1 would only be in scope in its then-clause, not throughout the entire if-statement, but that's not how the C++ spec looks.)
https://godbolt.org/z/118vGjE43
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145757] llvm-objdump disassemly does not correctly decode data references in PIC code?
Issue
145757
Summary
llvm-objdump disassemly does not correctly decode data references in PIC code?
Labels
tools:llvm-objdump,
new issue
Assignees
Reporter
MatzeB
Reproducer:
test.c:
```
int foo = 0;
int get_foo() { return foo; }
void set_foo(int val) { foo = val; }
```
compile and dump:
```
$ clang -fPIC -shared -o libtest.so test.c
$ llvm-objdump -d libtest.so
...
1100 :
1100: 55pushq %rbp
1101: 48 89 e5 movq%rsp, %rbp
1104: 48 8b 05 dd 2e 00 00 movq 0x2edd(%rip), %rax # 0x3fe8 <__gmon_start__+0x3fe8>
110b: 8b 00 movl(%rax), %eax
110d: 5d popq%rbp
110e: c3retq
110f: 90nop
1110 :
1110: 55pushq %rbp
: 48 89 e5 movq%rsp, %rbp
1114: 89 7d fc movl %edi, -0x4(%rbp)
1117: 8b 4d fc movl-0x4(%rbp), %ecx
111a: 48 8b 05 c7 2e 00 00 movq0x2ec7(%rip), %rax # 0x3fe8 <__gmon_start__+0x3fe8>
1121: 89 08 movl%ecx, (%rax)
1123: 5dpopq%rbp
1124: c3retq
```
Note that this says `__gmon_start__+0x3fe8` at the place where it references the `foo` variable.
GNU objdump gets this right and says:
```
...
1104: 48 8b 05 dd 2e 00 00mov0x2edd(%rip),%rax# 3fe8
...
111a: 48 8b 05 c7 2e 00 00mov 0x2ec7(%rip),%rax# 3fe8
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145715] Arrow keys to exit lldb's reverse history search inserts raw character while doing so
Issue 145715 Summary Arrow keys to exit lldb's reverse history search inserts raw character while doing so Labels lldb Assignees Reporter DavidSpickett OS Ubuntu 22.04.5 LTS, liedit installed from apt: ``` libedit-dev/jammy,now 3.1-20210910-1build1 arm64 [installed] libedit2/jammy,now 3.1-20210910-1build1 arm64 [installed,automatic] ``` I expect that searching history in lldb would work as it does in my terminal: * `ctrl+r` enters `(reverse-i-search)`':` * I start searching and find the command I want * I want to edit that command before running, so I press an arrow key, usually right * That exits the search mode and leaves the cursor one to the right of where it was ``` $ (reverse-i-search)`': (reverse-i-search)`ninj': ninja $ ninja ``` When you do this in LLDB it exits the mode but the raw character code is inserted for right arrow, instead of making the cursor move: ``` (lldb) watchpoint set variable a bck:set (lldb) watchpoint [Cset variable a ``` That `[C` is actually there it's not just a visual artifact: ``` (lldb) watchpoint [Cset variable a "[Cset" is not a valid subcommand of "watchpoint". Valid subcommands are: command, delete, disable, enable, ignore, and others. Use "help watchpoint" to find out more. ``` We know that we should exit but not that it needs to be handled as a special character. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145513] [HLSL][SPIRV] Fix wave tests from the offload test suite
Issue 145513 Summary [HLSL][SPIRV] Fix wave tests from the offload test suite Labels HLSL, backend:SPIR-V Assignees Keenuts Reporter s-perron The tests mentioned below all fail with clang with the same assert: ``` Assertion failed: HandleDef.getIntrinsicID() == Intrinsic::spv_resource_handlefrombinding, file E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\lib\Target\SPIRV\SPIRVInstructionSelector.cpp, line 4078 ``` ``` Failed Tests (4): OffloadTest-clang-vk :: Feature/WaveOps/WaveActiveAllTrue.test OffloadTest-clang-vk :: Feature/WaveOps/WaveActiveAnyTrue.test OffloadTest-clang-vk :: Feature/WaveOps/WaveActiveCountBits.test OffloadTest-clang-vk :: Feature/WaveOps/WaveIsFirstLane.test ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145505] [clang] `friend` declaration does not apply during constraint validation
Issue
145505
Summary
[clang] `friend` declaration does not apply during constraint validation
Labels
clang
Assignees
Reporter
yalavrinenko
I discovered that with the latest `clang-21` the following code stop compiling:
```c++
#include
template
concept FooType = requires (T *v){
{v->bar()} -> std::same_as;
};
template
struct Bar {
Bar(T *owner): owner_{owner}{}
bool func() {
return owner()->bar() == 10;
}
auto owner() requires FooType {
return owner_;
}
T *owner_;
};
class Owner{
public:
auto& obj() { return obj_; }
private:
friend Bar;
int bar() { return 10; }
Bar obj_{this};
};
int main(){
Owner o;
return o.obj().func();
}
```
The compilation error is following:
```
:14:16: error: invalid reference to function 'owner': constraints not satisfied
14 | return owner()->bar() == 10;
|^
:38:20: note: in instantiation of member function 'Bar::func' requested here
38 | return o.obj().func();
|^
:17:27: note: because 'Owner' does not satisfy 'FooType'
17 | auto owner() requires FooType {
| ^
:6:9: note: because 'v->bar()' would be invalid: 'bar' is a private member of 'Owner'
6 | {v->bar()} -> std::same_as;
```
Link to godbolt: https://godbolt.org/z/PasxrhaEa
Compiler info:
```
> clang --version
Ubuntu clang version 21.0.0 (++20250623082046+1c78d8d9d7bc-1~exp1~20250623082206.2496)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-21/bin
```
The code above compiles with `gcc` as well as with `clang-20` and early version of `clang-21`. Unfortunately I can not provide the last working revision of `clang-21`.
Please clarify whether this behavior is expected?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145798] [clang-tidy] Check request: modernize-use-auto-temporary
Issue
145798
Summary
[clang-tidy] Check request: modernize-use-auto-temporary
Labels
clang-tidy
Assignees
Reporter
denzor200
C++23 suggests us the way to make a temporary copy of an object without creating a variable.
Need a check that fill find places in the code that mignt be improved using this new feature and will provide fixit hint to change that.
BEFORE:
```
void example(const auto& arg) {
const auto copy = get();
process(copy);
process(std::decay_t{arg});
}
```
AFTER:
```
void example(const auto& arg) {
process(auto{copy});
process(auto{arg});
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145788] Request Commit Access For rkirsling
Issue 145788 Summary Request Commit Access For rkirsling Labels infra:commit-access-request Assignees Reporter rkirsling ### Why are you requesting commit access ? I'm a compiler engineer at Sony Interactive Entertainment; contributing to Clang / LLVM would be smoother if I could add reviewers to my PRs and hit the merge button myself. Thanks! Contributions: - [[clang-format] Add SpaceBeforeCpp11BracedList option](https://github.com/llvm/llvm-project/commit/bfc340653022b00383c97db117719d15d20bdfa3)(Phabricator era, [D46024](https://reviews.llvm.org/D46024)) - https://github.com/llvm/llvm-project/pull/144069 - https://github.com/llvm/llvm-project/pull/144247 (trivial) - https://github.com/llvm/llvm-project/pull/144836 - https://github.com/llvm/llvm-project/pull/145105 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145787] [clang-tidy] Check request: bugprone-invalidated-std-erase
Issue
145787
Summary
[clang-tidy] Check request: bugprone-invalidated-std-erase
Labels
clang-tidy
Assignees
Reporter
denzor200
Needs a check that will find dangerous usages of `std::erase`.
```
void example() {
std::vector values{1, 1, 2, 3, 1, 4};
std::erase(values, values.front()); // WARNING
}
```
Correct way to write the same logic is to make a copy before erase:
```
void example() {
std::vector values{1, 1, 2, 3, 1, 4};
const auto copy = values.front();
std::erase(values, copy); // OK
}
```
BTW, is it possible to provide such fixit hint? I never seen a Clang Tidy's fixit that provides such transformation.
In C++23 mode this check will definitely provide fixit:
```
void example() {
std::vector values{1, 1, 2, 3, 1, 4};
std::erase(values, auto{values.front()}); // OK
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145782] [DirectX] Should DXILDataScalarization the Alloca visitor be checking for Vectors and Arrays of Vectors?
Issue 145782 Summary [DirectX] Should DXILDataScalarization the Alloca visitor be checking for Vectors and Arrays of Vectors? Labels new issue, backend:DirectX Assignees farzonl Reporter farzonl We currently just are checking for Arrays of vectors. That means its possible we aren't transforming alloca of vectors to arrays. https://github.com/llvm/llvm-project/blob/2f817d1c9e7341d634931e3deb3f849ce67035da/llvm/lib/Target/DirectX/DXILDataScalarization.cpp#L127 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 145745] Clang 20.1.0 Compiler Internal Error (Crash) during AST Parsing of C++23
Issue
145745
Summary
Clang 20.1.0 Compiler Internal Error (Crash) during AST Parsing of C++23
Labels
clang
Assignees
Reporter
0xSqualo
Clang 20.1.0 crashes with an unhandled internal error, when compiling a specific C++23 source file, and requests that this issue be reported to the LLVM project.
This issue was discovered using Boost 1.83.0 and Clang 20.1.0, which highlights the issue is in the AST parsing logic.
It seems that this issue could potentially be due to AST parsing during the [`_do_erased_copy(...)` call internal to `status_code_domain.hpp`](https://github.com/boostorg/outcome/blob/b3bc4b9360e1b2110c33716a2616a54d60c1de72/include/boost/outcome/experimental/status-code/status-code/status_code_domain.hpp#L451), however this root cause is not certain.
### PoC
See example with full crash on godbolt: https://godbolt.org/z/crG13rjo9
This issue can otherwise be reproduced with:
- `clang-20`: version `20.1.0`
- Boost: version `1.83.0`
And using a basic entrypoint that includes the boost header which triggers the AST issue:
```c++
// main.cpp
#include
int main() {
return 0;
}
```
For full reproducability locally, I used (on Ubuntu `25.04`):
`CMakeLists.txt`:
```CMakeLists.txt
cmake_minimum_required(VERSION 3.30)
project(clang-20-issue)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
find_package(Boost REQUIRED EXACT 1.83.0)
set(TARGET_NAME a.out)
add_executable(${TARGET_NAME} main.cpp)
target_link_libraries(${TARGET_NAME} PRIVATE ${Boost_LIBRARIES})
target_include_directories(${TARGET_NAME} PRIVATE ${Boost_INCLUDE_DIRS})
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD 23)
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD_REQUIRED ON)
```
And this `build.sh` build script:
```bash
mkdir -p build
CC=clang-20 CXX=clang++-20 cmake . -B build
cmake --build build
```
Which reproduces the same AST crash as on godbolt.
For reference:
```bash
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-20.1.0/bin/clang++ -gdwarf-4 -g -o /app/output.s -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-14.2.0 -fcolor-diagnostics -fno-crash-diagnostics -std=gnu++23 -isystem/opt/compiler-explorer/libs/boost_1_83_0
1. /opt/compiler-explorer/libs/boost_1_83_0/boost/outcome/experimental/status-code/status-code/status_code_domain.hpp:451:30: current parser token ')'
2. /opt/compiler-explorer/libs/boost_1_83_0/boost/outcome/experimental/status-code/status-code/status_code_domain.hpp:38:1 : parsing namespace 'system_error2'
3. /opt/compiler-explorer/libs/boost_1_83_0/boost/outcome/experimental/status-code/status-code/status_code_domain.hpp:110:1: parsing struct/union/class body 'system_error2::status_code_domain'
4. /opt/compiler-explorer/libs/boost_1_83_0/boost/outcome/experimental/status-code/status-code/status_code_domain.hpp:443:3: parsing function body 'system_error2::status_code_domain::_do_erased_copy'
5. /opt/compiler-explorer/libs/boost_1_83_0/boost/outcome/experimental/status-code/status-code/status_code_domain.hpp:443:3: in compound statement ('{}')
#0 0x03a59568 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x3a59568)
#1 0x03a576ac llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x3a576ac)
#2 0x039a69e8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x793ca9242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x07769b20 clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x7769b20)
#5 0x071b4651 clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x71b4651)
#6 0x0719e68b clang::ASTContext::getTypeInfo(clang::Type const*) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x719e68b)
#7 0x0719e68b clang::ASTContext::getTypeInfo(clang::Type const*) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x719e68b)
#8 0x0719e68b clang::ASTContext::getTypeInfo(clang::Type const*) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x719e68b)
#9 0x071b556b clang::ASTContext::getTypeInfoInChars(clang::Type const*) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x71b556b)
#10 0x071b5ec9 clang::ASTContext::getTypeSizeInChars(clang::QualType) const (/opt/compiler-explorer/clang-20.1.0/bin/clang+++0x71b5ec9)
#11 0x07444ad3 HandleSizeof((anonymous namespace)::EvalInfo&, clang::SourceLocation, clang::QualType, clang::CharUnits&, SizeOfType) ExprConstant.cpp:0:0
