[llvm-bugs] [Bug 89705] -fasm-blocks disables implicit return from main
Issue 89705 Summary -fasm-blocks disables implicit return from main Labels new issue Assignees Reporter gldrk https://godbolt.org/z/rP3bh4WcK ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89704] -fasm-blocks ignores partial register update
Issue 89704 Summary -fasm-blocks ignores partial register update Labels new issue Assignees Reporter gldrk https://godbolt.org/z/KGhE8d15c ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89700] llvm-split replaces symbolic links with the referenced file.
Issue 89700 Summary llvm-split replaces symbolic links with the referenced file. Labels new issue Assignees Reporter ian-collins-ctct We had `ls -l ../built/third_party_libs/libfastrtps.so* lrwxrwxrwx 1 ian sudo 18 Mar 1 21:12 ../built/third_party_libs/r2/libfastrtps.so -> libfastrtps.so.2.6 lrwxrwxrwx 1 ian sudo 20 Mar 1 21:12 ../built/third_party_libs/r2/libfastrtps.so.2.6 -> libfastrtps.so.2.6.6 -rw-r--r-- 1 ian sudo 5926028 Apr 23 14:00 ../built/third_party_libs/r2/libfastrtps.so.2.6.6` After running llvm-strip-16 on "*.so" this changed to `-rw-r--r-- 1 ian sudo 5926028 Apr 23 13:58 ../built/third_party_libs/r2/libfastrtps.so lrwxrwxrwx 1 ian sudo 20 Mar 1 21:12 ../built/third_party_libs/r2/libfastrtps.so.2.6 -> libfastrtps.so.2.6.6 -rw-r--r-- 1 ian sudo 5926028 Apr 23 13:58 ../built/third_party_libs/r2/libfastrtps.so.2.6.6` The build previously use gnu spit which did not mess with the symlinks. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89699] [clang/c++] Very strange/bad optimizer behavior.
Issue
89699
Summary
[clang/c++] Very strange/bad optimizer behavior.
Labels
clang
Assignees
Reporter
no-more-secrets
Problem demo: https://godbolt.org/z/zfMohEMj7
The "good" variant produces perfectly optimized code, while the nearly-identical "bad" variant produces a giant explosion of seemingly unoptimized code.
```c++
static int len( char const* input ) {
return std::string( input ).size();
}
int test() {
return
#ifdef GOOD
len( "h" ) + len( "h" );
#else /*BAD*/
len( "h" ) + len( "" );
#endif
}
```
This (regression?) happened between Clang versions 13 and 14: https://godbolt.org/z/brhYEK4Eh
The problem does not exist in gcc: https://godbolt.org/z/Ed6z6j61a
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89696] [clang-format] Failure when formatting a nested structure containing a lint-suppression comment
Issue
89696
Summary
[clang-format] Failure when formatting a nested structure containing a lint-suppression comment
Labels
clang-format
Assignees
Reporter
mitchgrout
**Version**: 17.0.2
**Platform**: Windows 10 (mingw64), x86_64
**.clang-format**:
```yml
---
BasedOnStyle: LLVM
Language: Cpp
Standard: c++17
ColumnLimit:120
AlignArrayOfStructures: Left
```
**main.c**:
```c
object_t obj =
{
.outer =
{
.w = 0,
.x = 1, //lint some comment here
.y = 2,
.z = 3
}
};
```
Running the command `clang-format -style=file main.c` triggers a failure with the following stack dump:
```
Stack dump:
0. Program arguments: "C:\\Program Files\\LLVM\\bin\\clang-format.exe" -style=file main.c
Exception Code: 0xC005
#0 0x7ff744ab591b C:\Program Files\LLVM\bin\clang-format.exe 0xe591b C:\Program Files\LLVM\bin\clang-format.exe 0xe5373
#1 0x7ff744ab591b C:\Program Files\LLVM\bin\clang-format.exe 0xe3c20 C:\Program Files\LLVM\bin\clang-format.exe 0xe0d26
#2 0x7ff744ab591b C:\Program Files\LLVM\bin\clang-format.exe 0x5bd3d C:\Program Files\LLVM\bin\clang-format.exe 0xc54d1
#3 0x7ff744ab591b C:\Program Files\LLVM\bin\clang-format.exe 0x6eed7 C:\Program Files\LLVM\bin\clang-format.exe 0x51462
#4 0x7ff744ab591b C:\Program Files\LLVM\bin\clang-format.exe 0x53e89 C:\Program Files\LLVM\bin\clang-format.exe 0x572d
#5 0x7ff744ab591b C:\Program Files\LLVM\bin\clang-format.exe 0x39b6 C:\Program Files\LLVM\bin\clang-format.exe 0x1b0d40
#6 0x7ff744ab591b (C:\Program Files\LLVM\bin\clang-format.exe+0xe591b)
#7 0x7ff744ab5373 (C:\Program Files\LLVM\bin\clang-format.exe+0xe5373)
0x7FF744AB591B, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0xE591B byte(s)
0x7FF744AB5373, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0xE5373 byte(s)
0x7FF744AB3C20, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0xE3C20 byte(s)
0x7FF744AB0D26, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0xE0D26 byte(s)
0x7FF744A2BD3D, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x5BD3D byte(s)
0x7FF744A954D1, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0xC54D1 byte(s)
0x7FF744A3EED7, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x6EED7 byte(s)
0x7FF744A21462, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x51462 byte(s)
0x7FF744A23E89, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x53E89 byte(s)
0x7FF7449D572D, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x572D byte(s)
0x7FF7449D39B6, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x39B6 byte(s)
0x7FF744B80D40, C:\Program Files\LLVM\bin\clang-format.exe(0x7FF7449D) + 0x1B0D40 byte(s)
0x7FFC55B27344, C:\Windows\System32\KERNEL32.DLL(0x7FFC55B1) + 0x17344 byte(s), BaseThreadInitThunk() + 0x14 byte(s)
0x7FFC55E026B1, C:\Windows\SYSTEM32\ntdll.dll(0x7FFC55DB) + 0x526B1 byte(s), RtlUserThreadStart() + 0x21 byte(s)
```
This is a stripped-down example from a larger code-base. `object_t` represents a union, with `.outer` being one of the possible variants. Some extra notes:
- If a trailing comma is attached to `.z`, no failure occurs, but `.y` will be de-dented heavily
- If `.w` is removed, no error occurs
- If a space between `//` and `lint` is added, no error occurs
- If the comment is removed, no error occurs
- If the `.outer` declaration is removed, no error occurs
- If `AlignArrayOfStructures` is removed, no error occurs
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89695] void arguments in function types are not accepted
Issue 89695 Summary void arguments in function types are not accepted Labels new issue Assignees Reporter Halalaluyafail3 While looking at the behavior for qualified void return types (which clang gets wrong) I found that clang doesn't accept void function arguments. For example: ```c void f(void x); ``` This code should be valid just like how the following is accepted: ```c void g(struct undef x); ``` Both `f` and `g` have arguments of incomplete types but that is OK as long as these functions aren't called and because these are not function definitions. However, clang seems to diagnose `f` which is incorrect. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 68239 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: verifyVPlanIsValid(*Plan) && "VPlan is invalid"
Status: New Owner: CC: k...@google.com, masc...@google.com, igm...@gmail.com, sammcc...@google.com, da...@adalogics.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, jo...@devlieghere.com, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2024-04-22 Type: Bug New issue 68239 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: verifyVPlanIsValid(*Plan) && "VPlan is invalid" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68239 Detailed Report: https://oss-fuzz.com/testcase?key=5788250825359360 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: verifyVPlanIsValid(*Plan) && "VPlan is invalid" llvm::LoopVectorizationPlanner::buildVPlansWithVPRecipes llvm::LoopVectorizationPlanner::plan Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=202401170617:202404160629 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5788250825359360 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89676] [libc++] wstring_convert::from_bytes Fails on Identity Conversions
Issue
89676
Summary
[libc++] wstring_convert::from_bytes Fails on Identity Conversions
Labels
libc++
Assignees
Reporter
tommkelly
It appears that [`wstring_convert::from_bytes(const char*, const char*)`](https://en.cppreference.com/w/cpp/locale/wstring_convert/from_bytes) can fail erroneously--even throwing an exception--when specialized with the Identity Conversion and `Elem` type `char`, that is:
```
std::wstring_convert, char>
```
This came up for me when writing cross-platform code meant to compile on both Windows and Linux. I needed to format file names as input for [`std::filesystem::file_size`](https://en.cppreference.com/w/cpp/filesystem/file_size), so I defined a `wstring_convert` in terms of `std::filesystem::path::value_type`, which should be `wchar_t` on Windows and `char` on Linux.
For the latter: one would expect `from_bytes` to return a `basic_string` exactly equivalent to the input, but instead: the method threw a `range_error` (the expected behavior when `from_bytes` encounters an error and the user hasn't provided an error `wstring`).
I believe the culprit lies [here](https://github.com/llvm/llvm-project/blob/b8ff08d0e668e5397dd799b76ede0bd54fcba75c/libcxx/include/locale#L3225) in **llvm-project/libcxx/include/locale**:
```
__r = __cvtptr_->in(__st, __frm, __frm_end, __frm_nxt, __to, __to_end, __to_nxt);
__cvtcount_ += __frm_nxt - __frm;
if (__frm_nxt == __frm) {
__r = codecvt_base::error;
} else if (__r == codecvt_base::noconv) {
__ws.resize(__to - &__ws[0]);
//This only gets executed if _Elem is char
__ws.append((const _Elem*)__frm, (const _Elem*)__frm_end);
__frm = __frm_nxt;
__r = codecvt_base::ok;
} else if ...
```
>From the [documentation](https://en.cppreference.com/w/cpp/locale/codecvt/in) of `std::codecvt::in`:
> Leaves `from_next` and `to_next` pointing one beyond the last element successfully converted.
...
If this `codecvt` facet does not define a conversion, no characters are converted. `to_next` is set to be equal to `to`, `state` is unchanged, and [`std::codecvt_base::noconv`](https://en.cppreference.com/w/cpp/locale/codecvt_base) is returned.
This unfortunately doesn't specify the expected value of `from_next` after function execution in the `noconv` case, but one can infer by definition that it at least *may* behave similarly to `to_next`; i.e. `from_next` is set to `from` if `in` returns `std::codecvt_base::noconv`, and my own observations via debugger corroborate this.
In other words: it seems that this implementation of `from_bytes` is circumventing its own `noconv` case by first checking whether `__frm_next == __frm`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89674] lldb/include/lldb/Utility/ProcessInfo.h:236: Same expression on both sides of '||'
Issue
89674
Summary
lldb/include/lldb/Utility/ProcessInfo.h:236: Same _expression_ on both sides of '||'
Labels
lldb
Assignees
Reporter
dcb314
Source code is
bool CumulativeSystemTimeIsValid() const {
return m_cumulative_system_time.tv_sec > 0 ||
m_cumulative_system_time.tv_sec > 0;
}
Suggest code rework.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89673] error: Invalid cast (Producer: 'LLVM18.0.1' Reader: 'LLVM 18.0.1'
Issue 89673 Summary error: Invalid cast (Producer: 'LLVM18.0.1' Reader: 'LLVM 18.0.1' Labels new issue Assignees Reporter hiraditya Repro: [beacon.i.txt](https://github.com/llvm/llvm-project/files/15068800/beacon.i.txt) ``` clang -c -msse3 -mstackrealign -O2 -faddrsig -fdebug-default-version=5 -fcolor-diagnostics -ffp-contract=off -fno-exceptions -fno-strict-aliasing -fmessage-length=0 -gsimple-template-names -gz=zstd -no-canonical-prefixes -Wno-error=format -fdebug-prefix-map=/proc/self/cwd= -ftrivial-auto-var-init=zero -g -ffunction-sections -fdata-sections -fno-short-enums -funwind-tables -fstack-protector-strong -Wa,--noexecstack -D_FORTIFY_SOURCE=2 -nostdlibinc -fdebug-info-for-profiling -m32 -march=prescott -target i686-linux-android1 -fPIE -flto -fsanitize-cfi-cross-dso -fsanitize-ignorelist=external/compiler-rt/lib/cfi/cfi_blocklist.txt -fvisibility=default -fsanitize=cfi -fsanitize-trap=all -std=gnu17 -fcommon beacon.i ``` $ llvm-project/build/bin/opt -S beacon.o ``` llvm-project/build/bin/opt: beacon.o: error: Invalid cast (Producer: 'LLVM18.0.1' Reader: 'LLVM 18.0.1') ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89672] coalescing of redundant vector stores isn't preserving alignment correctly
Issue
89672
Summary
coalescing of redundant vector stores isn't preserving alignment correctly
Labels
new issue
Assignees
Reporter
regehr
https://alive2.llvm.org/ce/z/-qQphe
optimizing this code:
```llvm
define i32 @f(ptr %0, i1 %1) {
store <2 x i64> zeroinitializer, ptr %0, align 8
br i1 %1, label %4, label %3
3: ; preds = %2
store <2 x i64> zeroinitializer, ptr %0, align 16
br label %4
4: ; preds = %3, %2
ret i32 0
}
```
is mostly doing what we expect, but the coalesced store should retain the smaller alignnment value of the two, not the larger:
```lllvm
; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: write)
define noundef i32 @f(ptr nocapture writeonly %0, i1 %1) local_unnamed_addr #0 {
store <2 x i64> zeroinitializer, ptr %0, align 16
ret i32 0
}
attributes #0 = { mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: write) }
```
cc @nunoplopes @hatsunespica
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89671] coalescing of redundant vector stores isn't preserving alignment correctly
Issue 89671 Summary coalescing of redundant vector stores isn't preserving alignment correctly Labels new issue Assignees Reporter regehr ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89670] Sanitizer handler calls emitted without regard to `-mregparm`
Issue 89670 Summary Sanitizer handler calls emitted without regard to `-mregparm` Labels new issue Assignees Reporter kees When sanitizer calls are emitted, the `-mregparm=3` option used by the Linux kernel appears to be ignored. For example, here is a build where the argument are being pushed instead of placed in `%eax` and `%edx` (from `lkdtm_ARRAY_BOUNDS`): ```asm 0xc18e3a5a <+202>: push %ebx 0xc18e3a5b <+203>: push $0xc26001a0 0xc18e3a60 <+208>: call 0xc157d430 <__ubsan_handle_out_of_bounds> ``` The kernel's handler isn't expecting them on the stack. For example, this is setting a bit in the sanitizer's passed-in data structure (from `__ubsan_handle_out_of_bounds`): ```asm 0xc157d491 <+97>: btsl $0x1f,%ds:0x4(%eax) 0xc157d497 <+103>: jae0xc157d4a1 <__ubsan_handle_out_of_bounds+113> ``` https://github.com/KSPP/linux/issues/350 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89669] miscompile of vector double-negation + select by InstCombine
Issue
89669
Summary
miscompile of vector double-negation + select by InstCombine
Labels
miscompilation,
llvm:instcombine
Assignees
Reporter
regehr
https://alive2.llvm.org/ce/z/N1RVAr
this:
```llvm
define <4 x i32> @f(<4 x i32> %0) {
%2 = sub <4 x i32> zeroinitializer, %0
%3 = select <4 x i1> , <4 x i32> %2, <4 x i32> %0
%4 = sub <4 x i32> zeroinitializer, %3
ret <4 x i32> %4
}
```
is being optimized to:
```llvm
define <4 x i32> @f(<4 x i32> %0) {
ret <4 x i32> %0
}
```
here's Alive's work about what this is wrong:
```
ERROR: Value mismatch
Example:
<4 x i32> %#0 = < #x0001 (1), poison, poison, poison >
Source:
<4 x i32> %#2 = < #x (4294967295, -1), poison, poison, poison >
<4 x i32> %#3 = < #x0001 (1), poison, poison, poison >
<4 x i32> %#4 = < #x (4294967295, -1), poison, poison, poison >
Target:
Source value: < #x (4294967295, -1), poison, poison, poison >
Target value: < #x0001 (1), poison, poison, poison >
```
cc @nunoplopes @hatsunespica
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89668] Fixed point integral sqrt (uksqrtui) crashes with LIBC_FAST_MATH and produces an incorrect value without LIBC_FAST_MATH
Issue
89668
Summary
Fixed point integral sqrt (uksqrtui) crashes with LIBC_FAST_MATH and produces an incorrect value without LIBC_FAST_MATH
Labels
bug,
libc
Assignees
lntue
Reporter
PiJoules
```
#include
#include
extern "C" unsigned _Accum uksqrtui(uint32_t);
int main() {
unsigned _Accum x = uksqrtui(65529);
printf("%f\n", (float)x);
}
```
This will crash with `integer divide by zero` on an x86-64 linux. It looks like the main reason for this is the `FastFractType` for `SqrtConfig` is a 16-bit `unsigned fract`, so when we get to `FracType r = a * x_frac + b;`, we end up with `(0x820c * 0xfff9) // 2**16 + 0x7df8 == 0x1` but we only retain the lower 16 bits for an unsigned fract. This is with `LIBC_FAST_MATH`.
Without `LIBC_FAST_MATH`, the error seems less clear and this will produce a value of `3.953979`. The final decimal result for either of these modes should be around `255.98632775990205`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89667] [libc][docs] Should we add types, symbolic constants to implementation status docgen pages?
Issue 89667 Summary [libc][docs] Should we add types, symbolic constants to implementation status docgen pages? Labels libc Assignees Reporter Flandini Addressing comments from https://github.com/llvm/llvm-project/pull/89421#issuecomment-2070949464. Tagging @nickdesaulniers ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89663] [HLSL] Track HLSL "standard library" Implementation
Issue 89663 Summary [HLSL] Track HLSL "standard library" Implementation Labels HLSL Assignees Reporter damyanp HLSL has many intrinsics, functions and data types that will need to be implemented. We need a centralized list of all these things, which shader model and stages they apply to, and the state of the implementation of each one. The list needs to be publicly available, linked to issues in github, and able to automatically updated based on the states of the issues. > *Open Question* - should we expand this to cover tracking DXIL op implementations? Maybe for each thing we track here we cover from HLSL lowered down to final IR? # Acceptance Criteria - [ ] Anyone can easily find the current progress of intrinsic implementations - [ ] Systems are in place so we can be confident that the information is up to date (or is at least updateable) - [ ] Issues have been created for at least all intrinsics we plan implement over the next 6 months # Subtasks - [ ] Design method for tracking and reporting this - [ ] Collect data for intrinsics - [ ] Collect data for built in types & APIs - [ ] anything else?? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89661] [compiler warning]: comparison of integers of different signs: 'const int' and 'const unsigned long
Issue
89661
Summary
[compiler warning]: comparison of integers of different signs: 'const int' and 'const unsigned long
Labels
new issue
Assignees
Reporter
hiraditya
Comparing `0` with uint64_t value results in compiler warning. Does it make sense?
```cpp
#include
#include
#include
template
std::string CmpHelperOpFailure(const char* expr1, const char* expr2,
const T1& val1, const T2& val2,
const char* op) {
return "failed";
}
#define GTEST_IMPL_CMP_HELPER_(op_name, op)\
template \
std::string CmpHelper##op_name(const char* expr1, const char* expr2, \
const T1& val1, const T2& val2) { \
if (val1 op val2) { \
return "PASS"; \
} else { \
return CmpHelperOpFailure(expr1, expr2, val1, val2, #op); \
} \
}
GTEST_IMPL_CMP_HELPER_(NE, !=)
#define ASSERT_PRED_FORMAT2(Fun, val1, val2) Fun(#val1, #val2, val1, val2)
#define GTEST_ASSERT_NE(val1, val2) \
ASSERT_PRED_FORMAT2(CmpHelperNE, val1, val2)
#define ASSERT_NE(Op1, Op2) GTEST_ASSERT_NE(Op1, Op2)
uint64_t bar() {
return 100;
}
int foo(uint64_t l) {
ASSERT_NE(0, bar());
return 0;
}
```
$ clang++ -Wsign-compare test.cpp
```
:24:28: error: comparison of integers of different signs: 'const int' and 'const unsigned long' [-Werror,-Wsign-compare]
24 | GTEST_IMPL_CMP_HELPER_(NE, !=)
| ~~~^~~
:17:14: note: expanded from macro 'GTEST_IMPL_CMP_HELPER_'
17 | if (val1 op val2) { \
| ^
:39:5: note: in instantiation of function template specialization 'CmpHelperNE' requested here
39 | ASSERT_NE(0, bar());
| ^
:32:29: note: expanded from macro 'ASSERT_NE'
32 | #define ASSERT_NE(Op1, Op2) GTEST_ASSERT_NE(Op1, Op2)
| ^
:30:23: note: expanded from macro 'GTEST_ASSERT_NE'
30 | ASSERT_PRED_FORMAT2(CmpHelperNE, val1, val2)
| ^
1 error generated.
Compiler returned: 1
```
https://godbolt.org/z/qxPEd986n
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89651] [libc] are compiler flags being cached?
Issue 89651 Summary [libc] are compiler flags being cached? Labels build-problem, libc Assignees Reporter nickdesaulniers So in https://github.com/llvm/llvm-project/pull/87837, I'm trying to fix the failing setjmp/longjmp tests, but curiously none of the post submit bots have failed... I wonder if the compiler flags are being cached in the cmake build? IIRC, there was something in cmake syntax where you could say `set(foo value CACHE OFF)` or something to stop that. Perhaps that (or whatever it is that I'm thinking of, or something else) is needed here? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89647] [libc][math][c23] Implement C23 math function log2p1f
Issue 89647 Summary [libc][math][c23] Implement C23 math function log2p1f Labels libc Assignees Reporter overmighty Please assign this to me if you have write access to the repository. cc @lntue ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89646] [DirectX backend] flatten multi-dimensional array into a one-dimensional array.
Issue 89646 Summary [DirectX backend] flatten multi-dimensional array into a one-dimensional array. Labels backend:DirectX Assignees Reporter python3kgae DXIL requires array to be 1D only in https://github.com/Microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#arrays Need a pass in DirectX backend to flatten multi-dimensional array into a one-dimensional array. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89641] [HLSL] Propose generic bitfield intrinsics in LLVM
Issue 89641 Summary [HLSL] Propose generic bitfield intrinsics in LLVM Labels new issue Assignees Reporter bogner As per the conclusions in #87367, we should propose adding bitfield instructions as generic LLVM intrinsics. Specifically, we need operations for [Bfi](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#bfi), [Ibfe](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#ibfe), and [Ubfe](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#ubfe). These operations exist in several ISAs (sometimes spelled differently, as in BFX on ARM archs), so I think it's reasonable to argue that having a generic for intrinsic for them is useful. ### Acceptance Criteria - Either consensus from the LLVM community that we should add these operations, or a well reasoned rejection ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89635] LLVM ERROR: Broken module found, compilation aborted
Issue
89635
Summary
LLVM ERROR: Broken module found, compilation aborted
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run the following test with -passes slp-vectorizer -slp-threshold=-9
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
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-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define i32 @wombat(i32 %arg) #0 gc "statepoint-example" {
bb:
%or = or i32 %arg, 0
%mul = mul i32 0, 1
%mul1 = mul i32 %or, %mul
%sitofp = sitofp i32 %mul1 to float
%fcmp = fcmp ugt float 0.00e+00, %sitofp
%or2 = or i32 0, %or
%mul3 = mul i32 %mul, 0
%mul4 = mul i32 %or2, %mul3
%sitofp5 = sitofp i32 %mul4 to float
%fcmp6 = fcmp ugt float 0.00e+00, %sitofp5
ret i32 0
}
```
Reproducer: https://godbolt.org/z/qW6c8ovEh
Stack dump:
```
Instruction does not dominate all uses!
%mul = mul i32 0, 1
%1 = insertelement <2 x i32> %0, i32 %mul, i32 1
LLVM ERROR: Broken module found, compilation aborted!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/opt -o /app/output.s -S -passes slp-vectorizer -slp-threshold=-9
#0 0x04d1fff8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4d1fff8)
#1 0x04d1d74c SignalHandler(int) Signals.cpp:0:0
#2 0x7f0922e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7f0922e969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7f0922e42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7f0922e287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x007a7cc7 llvm::json::operator==(llvm::json::Value const&, llvm::json::Value const&) (.cold) JSON.cpp:0:0
#7 0x04c57178 (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4c57178)
#8 0x04b6aa13 (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4b6aa13)
#9 0x008be3fe llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x8be3fe)
#10 0x04b2e4bc llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4b2e4bc)
#11 0x008c8eb2 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::ArrayRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x8c8eb2)
#12 0x008bc705 optMain (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x8bc705)
#13 0x7f0922e29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#14 0x7f0922e29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#15 0x008b34ae _start (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x8b34ae)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89629] Nondeterminism in llvm-libc++-static.cfg.in :: std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
Issue 89629 Summary Nondeterminism in llvm-libc++-static.cfg.in :: std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp Labels bug, libc++ Assignees Reporter ilovepi We're seeing some non-deterministic failures in llvm-libc++-static.cfg.in :: std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp in our CI (https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8750473375533143361/overview). It's unclear why this is happening, and why sometimes this test passes w/o any (known) changes to our CI configuration/infrastructure or to libcxx. This appears related to https://github.com/llvm/llvm-project/commit/1fda1776e32b5582bfcfcbd8094f3c280d936cec, so I'm CCing @mordante. Below is the failing diff, which are only different in 2 lines. ``` # | libcxx # | ... # | America/Ciudad_Juarez Sun Feb 5 06:59:59 1939 UT = Sat Feb 4 23:59:59 1939 MST isdst=0 gmtoff=-25200 # | America/Ciudad_Juarez Sun Feb 5 07:00:00 1939 UT = Sun Feb 5 01:00:00 1939 CST isdst=0 gmtoff=-21600 # | ... ``` vs. ``` # | zdump # | ... # | America/Ciudad_Juarez Fri Apr 1 06:59:59 1932 UT = Thu Mar 31 23:59:59 1932 MST isdst=0 gmtoff=-25200 # | America/Ciudad_Juarez Fri Apr 1 07:00:00 1932 UT = Fri Apr 1 01:00:00 1932 CST isdst=0 gmtoff=-21600 # | ... ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89626] [HLSL][SPIRV] Add HLSL intrinsics like `any`, `all`, `lerp` to `SPIRVUsage.rst`
Issue 89626 Summary [HLSL][SPIRV] Add HLSL intrinsics like `any`, `all`, `lerp` to `SPIRVUsage.rst` Labels HLSL, backend:SPIR-V Assignees Reporter farzonl We have added a few HLSL intrinsics to the SPIRV backend, we should look into documenting these usages. _Originally posted by @VyacheslavLevytskyy in https://github.com/llvm/llvm-project/pull/88976#discussion_r1570604464_ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89621] In py3.11 SBThread.frames says 'SBThread' object is not iterable
Issue
89621
Summary
In py3.11 SBThread.frames says 'SBThread' object is not iterable
Labels
new issue
Assignees
Reporter
santhoshkumar-mani
In py3.11 SBThread.frames says 'SBThread' object is not iterable, same works fine in 3.8
Am using lldb version 8.0.1, is there any fix in recent versions ? i want to know if its worth upgrading
```
```
File "/usr/local/llvm80/lib/python3.11/site-packages/lldb/_init_.py", line 10506, in get_thread_frames
for frame in self:
TypeError: 'SBThread' object is not iterable
```
coming from here : /usr/local/llvm80/lib/python3.11/site-packages/lldb/{}init{}.py
```
10503 def get_thread_frames(self):
10504 '''An accessor function that returns a list() that contains all frames in a lldb.SBThread object.'''
10505 frames = []
10506 for frame in self:
10507 frames.append(frame)
10508 return frames
```
```
Same code in 3.8 returns SBThread as list, but not in 3.11
Swig is generating this file from lldb i guess
```
root# head -7 /usr/local/llvm80/lib/python3.11/site-packages/lldb/__init__.py
# This file was automatically generated by SWIG (https://www.swig.org).
# Version 4.1.1
#
# Do not make changes to this file unless you know what you are doing - modify
# the SWIG interface file instead.
swig_version = (4, 1, 1)
Dont see any problem in swig 4.1.1 generated code, as it supports py3.11 : [https://swig.org/#:~:text=Python%203.9%2D3.11%20support%20added., ](https://swig.org/#:~:text=Python%203.9%2D3.11%20support%20added.)unless its a open defect
```
Or py3.11 [improvisation](https://docs.python.org/3.11/whatsnew/3.11.html#:~:text=Old%2Dstyle%20frame%20objects%20are%20now%20created%20only%20when%20requested%20by%20debuggers%20or%20by%20Python%20introspection%20functions%20such%20as%20sys._getframe()%20and%20inspect.currentframe(), isnt allowing frames to be returned ?, lldb manual is clear though SBThread.frames should return the frames
https://lldb.llvm.org/python_api/lldb.SBThread.html#lldb.SBThread.frames
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89615] Invalid calling convention used for passing structures to varargs functions on ARM64EC
Issue
89615
Summary
Invalid calling convention used for passing structures to varargs functions on ARM64EC
Labels
new issue
Assignees
Reporter
julliard
On ARM64EC, passing structures to varargs functions uses the arm64 calling convention, but it should use the x64 convention, as documented at https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi#variadic-calling-convention
Below is a short test case showing that a 5-byte structure is passed by value, but according to the ARM64EC ABI it should be passed by reference:
```
struct s { char a, b, c, d, e; };
extern void foo( int a, ... );
void bar(void)
{
struct s s = { 1, 2, 3, 4, 5 };
foo( 0, s );
}
```
LLVM generates this (structure contents in x1):
```
0: d2804021 mov x1, #0x201
4: 910003e4 mov x4, sp
8: 2a1f03e0 mov w0, wzr
c: f2a08061 movk x1, #0x403, lsl #16
10: aa1f03e5 mov x5, xzr
14: f2c000a1 movk x1, #0x5, lsl #32
18: 1400 b 0x18 <.text+0x18>
```
while MSVC does this (structure contents on stack, pointer in x1):
```
0: f81f0ffe str x30, [sp, #-0x10]!
4: d10043ff sub sp, sp, #0x10
8: 910003e1 mov x1, sp
c: d280 mov x0, #0x0
10: 910003e4 mov x4, sp
14: d285 mov x5, #0x0
18: 52804028 mov w8, #0x201
1c: 72a08068 movk w8, #0x403, lsl #16
20: b90003e8 str w8, [sp]
24: 528000a8 mov w8, #0x5
28: 390013e8 strb w8, [sp, #0x4]
2c: 9400 bl 0x2c <.text$mn+0x2c>
30: 910043ff add sp, sp, #0x10
34: f84107fe ldr x30, [sp], #0x10
38: d65f03c0 ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89614] Assertion `(E->ReorderIndices.empty() || E != VectorizableTree.front().get() || !E->UserTreeIndices.empty()) && "PHI reordering is free."' failed.
Issue
89614
Summary
Assertion `(E->ReorderIndices.empty() || E != VectorizableTree.front().get() || !E->UserTreeIndices.empty()) && "PHI reordering is free."' failed.
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run the following test with -passes slp-vectorizer
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
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-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define void @wombat() #0 gc "statepoint-example" {
bb:
br label %bb1
bb1: ; preds = %bb1, %bb
%phi = phi i32 [ 0, %bb ], [ %mul33, %bb1 ]
%phi2 = phi i32 [ 0, %bb ], [ %phi3, %bb1 ]
%phi3 = phi i32 [ 0, %bb ], [ %phi2, %bb1 ]
%mul = mul i32 %phi2, %phi2
%mul4 = mul i32 %phi3, %mul
%mul5 = mul i32 %phi2, %mul4
%mul6 = mul i32 %phi3, %mul5
%mul7 = mul i32 %phi2, %mul6
%mul8 = mul i32 %phi3, %mul7
%mul9 = mul i32 %phi2, %mul8
%mul10 = mul i32 %phi3, %mul9
%mul11 = mul i32 %phi2, %mul10
%mul12 = mul i32 %phi3, %mul11
%mul13 = mul i32 %phi2, %mul12
%mul14 = mul i32 %phi3, %mul13
%mul15 = mul i32 %phi2, %mul14
%mul16 = mul i32 %phi3, %mul15
%mul17 = mul i32 %phi2, %mul16
%mul18 = mul i32 %phi3, %mul17
%mul19 = mul i32 %phi2, %mul18
%mul20 = mul i32 %phi3, %mul19
%mul21 = mul i32 %phi2, %mul20
%mul22 = mul i32 %phi3, %mul21
%mul23 = mul i32 %phi2, %mul22
%mul24 = mul i32 %phi3, %mul23
%mul25 = mul i32 %phi2, %mul24
%mul26 = mul i32 %phi3, %mul25
%mul27 = mul i32 %phi2, %mul26
%mul28 = mul i32 %phi3, %mul27
%mul29 = mul i32 %phi2, %mul28
%mul30 = mul i32 %phi3, %mul29
%mul31 = mul i32 %phi2, %mul30
%mul32 = mul i32 %phi3, %mul31
%mul33 = mul i32 %phi2, %mul32
br label %bb1
}
attributes #0 = { "target-cpu"="znver2" }
```
Reproducer:
https://godbolt.org/z/3eMYddMG1
Stack dump:
```
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/opt -o /app/output.s -S -passes slp-vectorizer
#0 0x04d1fff8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4d1fff8)
#1 0x04d1d74c SignalHandler(int) Signals.cpp:0:0
#2 0x7f1d81642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7f1d816969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7f1d81642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7f1d816287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x7f1d8162871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x7f1d81639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x03e89276 llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::slpvectorizer::BoUpSLP::TreeEntry*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x3e89276)
#9 0x03ea9b51 llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::MapVector, llvm::DenseMap, llvm::detail::DenseMapPair>, llvm::SmallVector>, 0u>> const&, llvm::SmallVectorImpl>&, llvm::Instruction*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x3ea9b51)
#10 0x03eb651d (anonymous namespace)::HorizontalReduction::tryToReduce(llvm::slpvectorizer::BoUpSLP&, llvm::DataLayout const&, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo const&) SLPVectorizer.cpp:0:0
#11 0x03eb8824 llvm::SLPVectorizerPass::vectorizeHorReduction(llvm::PHINode*, llvm::Instruction*, llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&, llvm::TargetTransformInfo*, llvm::SmallVectorImpl&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x3eb8824)
#12 0x03ebcdd8 llvm::SLPVectorizerPass::vectorizeRootInstruction(llvm::PHINode*, llvm::Instruction*, llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&, llvm::TargetTransformInfo*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x3ebcdd8)
#13 0x03ec0132 llvm::SLPVectorizerPass::vectorizeChainsInBlock(llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x3ec0132)
#14 0x03ec3987 llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) (.part.0) SLPVectorizer.cpp:0:0
#15 0x03ec4463 llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x3ec4463)
#16 0x02d7003e llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x2d7003e)
#17 0x00db61f4 llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&)
[llvm-bugs] [Bug 89610] How do I capture llc coverage in case of an llc execution crash???
Issue 89610 Summary How do I capture llc coverage in case of an llc execution crash??? Labels new issue Assignees Reporter cpython-java I can capture llc coverage by llvm-cov and llvm-profdata. But if the llc execution fails (crash as shown below), how can I capture its coverage ?? In this case, coverage files whose name is ends with ".profraw" fail to be generated so the previous method of getting coverage failed. If someone can help me, I will be very grateful!!! ``` LLVM ERROR: Function "main": over-aligned dynamic alloca not supported. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/compiler-explorer/clang-15.0.0/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple=sparcel 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'SPARC DAG->DAG Pattern Instruction Selection' on function '@main' #0 0x557b556c6404 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0 #1 0x557b556c3c64 SignalHandler(int) Signals.cpp:0:0 #2 0x7f1a61a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #3 0x7f1a61a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #4 0x7f1a61a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #5 0x7f1a61a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #6 0x557b52ebb813 llvm::DisplayGraph(llvm::StringRef, bool, llvm::GraphProgram::Name) (.cold) GraphWriter.cpp:0:0 #7 0x557b53d640b6 LowerDYNAMIC_STACKALLOC(llvm::SDValue, llvm::SelectionDAG&, llvm::SparcSubtarget const*) (.isra.0) SparcISelLowering.cpp:0:0 #8 0x557b53d73bee llvm::SparcTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x17b1bee) #9 0x557b553b64b8 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0 #10 0x557b553c4d2e llvm::SelectionDAG::Legalize() (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x2e02d2e) #11 0x557b554a6b77 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x2ee4b77) #12 0x557b554a98f1 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x2ee78f1) #13 0x557b554ac1f8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0 #14 0x557b549bc299 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0 #15 0x557b54e4ca60 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x288aa60) #16 0x557b54e4cbd9 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x288abd9) #17 0x557b54e4d7c0 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x288b7c0) #18 0x557b52f7a04b compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0 #19 0x557b52eca38a main (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x90838a) #20 0x7f1a61a29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90) #21 0x7f1a61a29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40) #22 0x557b52f7232e _start (/opt/compiler-explorer/clang-15.0.0/bin/llc+0x9b032e) Program terminated with signal: SIGSEGV Compiler returned: 139 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89600] vpand deferral eliminates earlier vpand elimination
Issue
89600
Summary
vpand deferral eliminates earlier vpand elimination
Labels
new issue
Assignees
Reporter
Validark
In my code, I have the following function:
```zig
export fn expand8xu8To16xu4AsByteVector(vec: @Vector(8, u8)) @Vector(16, u8) {
return std.simd.interlace(.{ vec, vec >> @splat(4) }) & @as(@Vector(16, u8), @splat(0xF));
}
```
Here is the Zen 3 assembly:
```asm
.LCPI0_0:
.zero 16,15
expand8xu8To16xu4AsByteVector:
vpsrlw xmm1, xmm0, 4
vpunpcklbw xmm0, xmm0, xmm1
vpand xmm0, xmm0, xmmword ptr [rip + .LCPI0_0]
ret
```
This implementation avoids an extraneous `vpand`, which LLVM unfortunately inserts in an implementation like:
```zig
export fn expand8xu8To16xu4AsByteVectorBad(vec: @Vector(8, u8)) @Vector(16, u8) {
return std.simd.interlace(.{ vec & @as(@Vector(8, u8), @splat(0xF)), vec >> @splat(4) })
}
```
```asm
.LCPI0_0:
.byte 15
.byte 15
.byte 15
.byte 15
.byte 15
.byte 15
.byte 15
.byte 15
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.LCPI0_1:
.zero 16,15
expand8xu8To16xu4AsByteVectorBad:
vpand xmm1, xmm0, xmmword ptr [rip + .LCPI0_0]
vpsrlw xmm0, xmm0, 4
vpand xmm0, xmm0, xmmword ptr [rip + .LCPI0_1]
vpunpcklbw xmm0, xmm1, xmm0
ret
```
The optimization in my first version is helpful because x86 does not have a `vpsrlb` instruction, it only has `vpsrlw`, which means the lower byte in each 2-byte pair will have 4 bits shifted in from the upper byte, requiring us to use a `vpand` to zero out the bits we don't want. But in this case, because we have to `vpand` to get the lowest 4 bits of the other vector we are interleaving anyway, we may as well interleave first, and then isolate the lowest 4 bits of all the bytes simultaneously.
Next, I define this function:
```zig
fn foo(vec: @Vector(16, u8)) [2]@Vector(16, u8) {
const vec2 = vec + vec;
const vec3 = vec2 | @as(@Vector(16, u8), @splat(1));
return @bitCast(std.simd.interlace(.{ vec2, vec3 }));
}
```
Zen 3 emit:
```asm
.LCPI1_0:
.zero 16,1
foo:
vpaddb xmm0, xmm0, xmm0; equivalent to multiply by 2 or shift left by 1
vporxmm1, xmm0, xmmword ptr [rip + .LCPI1_0]
vpunpckhbw xmm2, xmm0, xmm1
vpunpcklbw xmm0, xmm0, xmm1
```
The problem comes when I compose the two aforementioned functions:
```zig
export fn baz(x: u64) [2]@Vector(16, u8) {
return foo(expand8xu8To16xu4AsByteVector(@bitCast(x)));
}
```
```asm
.LCPI2_0:
.zero 16,15
.LCPI2_1:
.zero 16,30
.LCPI2_2:
.zero 16,1
baz:
vmovq xmm0, rdi
vpsrlw xmm1, xmm0, 4
vpand xmm1, xmm1, xmmword ptr [rip + .LCPI2_0]; Unnecessary! We wanted to avoid this instruction!
vpunpcklbw xmm0, xmm0, xmm1
vpaddb xmm0, xmm0, xmm0
vpand xmm0, xmm0, xmmword ptr [rip + .LCPI2_1]; LLVM tries to be cool here and use `0xF << 1` after `xmm0 + xmm0`
vporxmm1, xmm0, xmmword ptr [rip + .LCPI2_2]
vpunpckhbw xmm2, xmm0, xmm1
vpunpcklbw xmm0, xmm0, xmm1
```
Expected emit:
```asm
.LCPI2_1:
.zero 16,30
.LCPI2_2:
.zero 16,1
baz:
vmovq xmm0, rdi
vpsrlw xmm1, xmm0, 4
vpunpcklbw xmm0, xmm0, xmm1
vpaddb xmm0, xmm0, xmm0
vpand xmm0, xmm0, xmmword ptr [rip + .LCPI2_1]
vporxmm1, xmm0, xmmword ptr [rip + .LCPI2_2]
vpunpckhbw xmm2, xmm0, xmm1
vpunpcklbw xmm0, xmm0, xmm1
```
Alternatively (a less cool, but straightforward concatenation of the implementations of `expand8xu8To16xu4AsByteVector` and `foo`, where we `vpand` with `0xF` before the `vpaddb` rather than `vpand` with `0xF << 1` after the `vpaddb`):
```asm
.LCPI2_1:
.zero 16,15
.LCPI2_2:
.zero 16,1
baz:
vmovq xmm0, rdi
vpsrlw xmm1, xmm0, 4
vpunpcklbw xmm0, xmm0, xmm1
vpand xmm0, xmm0, xmmword ptr [rip + .LCPI2_1]
vpaddb xmm0, xmm0, xmm0
vporxmm1, xmm0, xmmword ptr [rip + .LCPI2_2]
vpunpckhbw xmm2, xmm0, xmm1
vpunpcklbw xmm0, xmm0, xmm1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89599] [Libc] Implement remquof128 function
Issue 89599 Summary [Libc] Implement remquof128 function Labels libc Assignees Reporter Sh0g0-1758 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89598] [Libc] Implement remainderf128 function
Issue 89598 Summary [Libc] Implement remainderf128 function Labels libc Assignees Reporter Sh0g0-1758 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89597] clang differs from gcc in the behaviourof -ffunction-sections and -fdata-sections
Issue
89597
Summary
clang differs from gcc in the behaviourof -ffunction-sections and -fdata-sections
Labels
clang
Assignees
Reporter
hutoushayu
example:
`
#include
#pragma clang section data=""
int g_aaa_5=123;
int fun_5(void)
{
printf("%s: %d\n", __FUNCTION__, __LINE__);
return 0;
}
#pragma clang section data=""
#pragma clang section data=""
int fun_1(void)
{
printf("%s: %d\n", __FUNCTION__, __LINE__);
return 0;
}
int fun_2(void)
{
printf("%s: %d\n", __FUNCTION__, __LINE__);
return 0;
}
int g_aaa_1=123;
int g_aaa_2=123;
#pragma clang section data=""
int g_aaa_3=123;
int g_aaa_4=123;
int fun_3(void)
{
printf("%s: %d\n", __FUNCTION__, __LINE__);
return 0;
}
int fun_4(void)
{
printf("%s: %d\n", __FUNCTION__, __LINE__);
return 0;
}
int main(void)
{
g_aaa_1=111;
g_aaa_3=111;
fun_1();
fun_3();
}`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89595] `readability-misleading-indentation` false positive on several stacked loops without indentation
Issue
89595
Summary
`readability-misleading-indentation` false positive on several stacked loops without indentation
Labels
new issue
Assignees
Reporter
HolyBlackCat
```cpp
int main()
{
for (int i = 0; i < 3; i++)
for (int j = 0; j < 3; j++)
{}
(void)42;
}
```
Analyzing with `clang-tidy 1.cpp -checks=readability-misleading-indentation -- -Wall -Wextra` results in a false positive:
```
1 warning generated.
/path/to/1.cpp:6:5: warning: misleading indentation: statement is indented too deeply [readability-misleading-indentation]
6 | (void)42;
| ^
/path/to/1.cpp:3:5: note: did you mean this line to be inside this 'for'
3 | for (int i = 0; i < 3; i++)
| ^
```
Using this indentation style for 2D loops is not unheard of, and it's a shame that clang-tidy warns about those. (The warning is otherwise useful, so I don't want to disable it everywhere.)
I suggest that this warning should be skipped for control statements with non-indented bodies.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89593] [clang-tidy] bugprone-optional-value-conversion - should ignore unevaluated context
Issue 89593 Summary [clang-tidy] bugprone-optional-value-conversion - should ignore unevaluated context Labels enhancement, clang-tools-extra, clang-tidy Assignees Reporter PiotrZSL Example: ``` static auto convert(const std::optional& input) -> custom::Optional ``` Same such go for static assert, noexcept, and so on... ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89591] libstdc++ sort does not work... well
Issue 89591 Summary libstdc++ sort does not work... well Labels new issue Assignees Reporter kelbon Recently I wanted to sort 2 separate arrays, one with the keys, the other with their corresponding values. A year ago this worked (iota } transform (tie(key, value)) + sort), but now, after improvements and corrections to the standard, this is no longer possible. But during the implementation process I discovered bugs/oddities in the libstd++ standard library: 1. even if range is std::sortable, stable_sort may be throw compilation error: https://godbolt.org/z/M8hWz1G7W This error may be even worse if you use 'size_t' indexes: https://godbolt.org/z/nzqqPWhd3 2. std::make_unsignedhas no specialization for __int128_t, but it is used: https://godbolt.org/z/GPa9E4h5a ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89582] Triple is normalized to unexpected value OS:none, ABI:elf
Issue 89582 Summary Triple is normalized to unexpected value OS:none, ABI:elf Labels new issue Assignees Reporter wzssyqa ``` $ clang --target=aarch64-none-elf --print-target-triple aarch64-none-unknown-elf $ clang --target=armv7m-none-eabi --print-target-triple armv7m-none-unknown-eabi ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89581] [x86] llvm #pragma pack behaviour is different from gcc
Issue
89581
Summary
[x86] llvm #pragma pack behaviour is different from gcc
Labels
new issue
Assignees
Reporter
zhangtianhao6
hello, I use #pragma pack(1) to change the ExampleStruct member align and print the address of ExampleStruct, the ExampleStruct address printed by the gcc compiler is 8-byte aligned, but the ExampleStruct address printed by the llvm compiler is 1-byte aligned. why they are different, which is correct?
```
#include
#include
#pragma pack(1)
struct ExampleStruct {
std::mutex mutex_;
int b;
};
#pragma pack()
ExampleStruct example;
int main(){
std::cout << << std::endl;
std::cout << alignof(example) << std::endl;
}
```
```
result:
gcc print: 0x404160
llvm print: 0x555d1805f031
```
godbolt demo:
https://godbolt.org/z/Yv7Taxfqa
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89579] [libc++] [modules] Defining __cpp_lib_modules
Issue 89579 Summary [libc++] [modules] Defining __cpp_lib_modules Labels libc++ Assignees Reporter ChuanqiXu9 See https://github.com/cppalliance/boost2/issues/1#issuecomment-2068737245 I guess the reason why libc++ doesn't define this is that it is still under experimental. I registered this issue to track this. Maybe we can define the macro earlier to make it easier for people to try it? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89576] LLVM ERROR: Error while trying to spill X8 from class GPR64: Cannot scavenge register without an emergency spill slot!
Issue
89576
Summary
LLVM ERROR: Error while trying to spill X8 from class GPR64: Cannot scavenge register without an emergency spill slot!
Labels
new issue
Assignees
Reporter
DigOrDog
# Description
The following code crashes aarch64 backend with "Error while trying to spill X8 from class GPR64: Cannot scavenge register without an emergency spill slot!!".
It's interesting that the command with -mtriple=aarch64 -O=2 results in an error, but the command with **-mtriple=aarch64 -O=0 does not produce an error**.
# Minimal Reproduction
https://godbolt.org/z/KcWovEv7q
## code
```
define double @f(i8 %0, i32 %1, i1 %L1, ptr %G.4, ptr %G.2, ptr %G.6, ptr %A4, ptr %A, ptr %G.8, ptr %G.9, ptr %G.11, ptr %G.13, ptr %G2, ptr %G3, ptr %G7, ptr %G5, ptr %G) {
BB:
%A42 = alloca i1, i32 0, align 1
br label %BB1
BB1: ; preds = %BB1, %BB
store i8 %0, ptr %A, align 1
store i1 true, ptr %A4, align 1
store i32 65536, ptr %G.8, align 4
store i1 false, ptr %G.9, align 1
%G6 = getelementptr double, ptr %A42, i8 42
store ptr %G.13, ptr %G6, align 8
store i32 %1, ptr %G.6, align 4
store float 0.00e+00, ptr %G.11, align 4
br i1 %L1, label %BB1, label %BB6
BB6: ; preds = %BB1
store i1 false, ptr %G.4, align 1
store i1 false, ptr %G2, align 1
store ptr %G3, ptr %G7, align 8
store i1 false, ptr %G.2, align 1
store ptr %G5, ptr %G, align 8
ret double 0.00e+00
}
```
## Stack Trace
```
LLVM ERROR: Error while trying to spill X8 from class GPR64: Cannot scavenge register without an emergency spill slot!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple=aarch64 -O=2
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@f'
#0 0x0394da58 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x394da58)
#1 0x0394b1ac SignalHandler(int) Signals.cpp:0:0
#2 0x7f0184842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7f01848969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7f0184842476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7f01848287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x00720037 (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x720037)
#7 0x02b7af8e llvm::RegScavenger::spill(llvm::Register, llvm::TargetRegisterClass const&, int, llvm::MachineInstrBundleIterator, llvm::MachineInstrBundleIterator&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2b7af8e)
#8 0x02b7b862 llvm::RegScavenger::scavengeRegisterBackwards(llvm::TargetRegisterClass const&, llvm::MachineInstrBundleIterator, bool, int, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2b7b862)
#9 0x02b7c910 scavengeFrameVirtualRegsInBlock(llvm::MachineRegisterInfo&, llvm::RegScavenger&, llvm::MachineBasicBlock&) RegisterScavenging.cpp:0:0
#10 0x02b7cda3 llvm::scavengeFrameVirtualRegs(llvm::MachineFunction&, llvm::RegScavenger&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2b7cda3)
#11 0x02ae3047 (anonymous namespace)::PEI::runOnMachineFunction(llvm::MachineFunction&) PrologEpilogInserter.cpp:0:0
#12 0x02961c51 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#13 0x02f20a13 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f20a13)
#14 0x02f20c51 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f20c51)
#15 0x02f214b5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f214b5)
#16 0x00828c2c compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#17 0x00727676 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x727676)
#18 0x7f0184829d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#19 0x7f0184829e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#20 0x0081f74e _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x81f74e)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89574] fatal error: error in backend: IO failure on output stream: No space left on device
Issue 89574 Summary fatal error: error in backend: IO failure on output stream: No space left on device Labels new issue Assignees Reporter contactvishwav clang -Wall -Werror -Wextra -Wpedantic -Wstrict-prototypes -c memory.c 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: clang -Wall -Werror -Wextra -Wpedantic -Wstrict-prototypes -c memory.c 1. parser at end of file Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x44)[0x9b8fac40] /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x70)[0x9b8f8c40] /lib/aarch64-linux-gnu/libLLVM-14.so.1(+0xd6cf6c)[0x9b82cf6c] /lib/aarch64-linux-gnu/libLLVM-14.so.1(+0xd6cef4)[0x9b82cef4] /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm3sys7Process4ExitEib+0x30)[0x9b8f53b0] clang[0x412dc8] /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm18report_fatal_errorERKNS_5TwineEb+0xfc)[0x9b83ae80] /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm14raw_fd_ostreamD1Ev+0x144)[0x9b8dee90] /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm14raw_fd_ostreamD0Ev+0x14)[0x9b8ddbcc] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZN5clang17EmitBackendOutputERNS_17DiagnosticsEngineERKNS_19HeaderSearchOptionsERKNS_14CodeGenOptionsERKNS_13TargetOptionsERKNS_11LangOptionsEN4llvm9StringRefEPNSE_6ModuleENS_13BackendActionESt10unique_ptrINSE_17raw_pwrite_streamESt14default_deleteISK_EE+0x2e0)[0xa24eaa68] /lib/aarch64-linux-gnu/libclang-cpp.so.14(+0x1ad5aa8)[0xa27a5aa8] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZN5clang8ParseASTERNS_4SemaEbb+0x210)[0xa16e70c4] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZN5clang14FrontendAction7ExecuteEv+0x80)[0xa309e834] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x328)[0xa3012fd8] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x218)[0xa3111cfc] clang(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x83c)[0x4129e4] clang[0x4111b4] /lib/aarch64-linux-gnu/libclang-cpp.so.14(+0x204ace4)[0xa2d1ace4] /lib/aarch64-linux-gnu/libLLVM-14.so.1(_ZN4llvm20CrashRecoveryContext9RunSafelyENS_12function_refIFvvEEE+0xcc)[0x9b82ce78] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZNK5clang6driver10CC1Command7ExecuteEN4llvm8ArrayRefINS2_8OptionalINS2_9StringRefEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPb+0x120)[0xa2d1a6e8] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZNK5clang6driver11Compilation14ExecuteCommandERKNS0_7CommandERPS3_+0x2b0)[0xa2cef714] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZNK5clang6driver11Compilation11ExecuteJobsERKNS0_7JobListERN4llvm15SmallVectorImplISt4pairIiPKNS0_7Command+0x7c)[0xa2cef950] /lib/aarch64-linux-gnu/libclang-cpp.so.14(_ZN5clang6driver6Driver18ExecuteCompilationERNS0_11CompilationERN4llvm15SmallVectorImplISt4pairIiPKNS0_7Command+0xd8)[0xa2d03704] clang(main+0x23d4)[0x410a08] /lib/aarch64-linux-gnu/libc.so.6(+0x273fc)[0x9a6373fc] /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9a6374cc] clang(_start+0x30)[0x40e2b0] make: *** [Makefile:19: memory.o] Error 1 The Makefile is attached below: ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89571] clang crashes when both '-lstdc++' '-ccc-print-phases' are on the command line
Issue
89571
Summary
clang crashes when both '-lstdc++' '-ccc-print-phases' are on the command line
Labels
clang
Assignees
Reporter
pudh4418
The following command line causes an assertion:
`clang -o m m.cpp -lstdc++ -ccc-print-phases`
```
+- 0: input, "m.cpp", c++
+- 1: preprocessor, {0}, c++-cpp-output
+- 2: compiler, {1}, ir
+- 3: backend, {2}, assembler
+- 4: assembler, {3}, object
clang: /data/A/llvm-project/llvm/include/llvm/ADT/SmallVector.h:308: const T& llvm::SmallVectorTemplateCommon >::operator[](llvm::SmallVectorTemplateCommon >::size_type) const [with T = const char*; = void; llvm::SmallVectorTemplateCommon >::const_reference = const char* const&; llvm::SmallVectorTemplateCommon >::size_type = long unsigned int]: Assertion `idx < size()' failed.
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: /data/A/llvm-project/build/bin/clang -o m m.cpp -lstdc++ -ccc-print-phases
1. Compilation construction
#0 0x5590ffdbfdd2 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (.localalias) /data/A/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22
#1 0x5590ffdc01e8 PrintStackTraceSignalHandler(void*) /data/A/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#2 0x5590ffdbd76e llvm::sys::RunSignalHandlers() (.localalias) /data/A/llvm-project/llvm/lib/Support/Signals.cpp:105:20
#3 0x5590ffdbf68c SignalHandler(int) /data/A/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#4 0x7fdf9d4a8420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#5 0x7fdf9cf4500b raise /build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x7fdf9cf24859 abort /build/glibc-wuryBv/glibc-2.31/stdlib/abort.c:81:7
#7 0x7fdf9cf24729 get_sysdep_segment_value /build/glibc-wuryBv/glibc-2.31/intl/loadmsgcat.c:509:8
#8 0x7fdf9cf24729 _nl_load_domain /build/glibc-wuryBv/glibc-2.31/intl/loadmsgcat.c:970:34
#9 0x7fdf9cf35fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#10 0x5590fda2d295 llvm::SmallVectorTemplateCommon::operator[](unsigned long) const /data/A/llvm-project/llvm/include/llvm/ADT/SmallVector.h:309:19
#11 0x5590fda2b15b llvm::opt::Arg::getValue(unsigned int) const /data/A/llvm-project/llvm/include/llvm/Option/Arg.h:126:20
#12 0x559100bc2e72 PrintActions1(clang::driver::Compilation const&, clang::driver::Action*, std::map, std::allocator > >&, llvm::Twine, int) /data/A/llvm-project/clang/lib/Driver/Driver.cpp:2342:46
#13 0x559100bc3143 PrintActions1(clang::driver::Compilation const&, clang::driver::Action*, std::map, std::allocator > >&, llvm::Twine, int) /data/A/llvm-project/clang/lib/Driver/Driver.cpp:2375:79
#14 0x559100bc34f3 clang::driver::Driver::PrintActions(clang::driver::Compilation const&) const (.localalias) /data/A/llvm-project/clang/lib/Driver/Driver.cpp:2415:18
#15 0x559100bbdcd2 clang::driver::Driver::BuildCompilation(llvm::ArrayRef) /data/A/llvm-project/clang/lib/Driver/Driver.cpp:1522:12
#16 0x5590fda28ff2 clang_main(int, char**, llvm::ToolContext const&) /data/A/llvm-project/clang/tools/driver/driver.cpp:361:66
#17 0x5590fda62e6a main /data/A/llvm-project/build/tools/clang/tools/driver/clang-driver.cpp:17:20
#18 0x7fdf9cf26083 __libc_start_main /build/glibc-wuryBv/glibc-2.31/csu/../csu/libc-start.c:342:3
#19 0x5590fda273ee _start (/data/A/llvm-project/build/bin/clang+0x30683ee)
Aborted
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
