[llvm-bugs] [Bug 52505] New: Add libclang API to set temporary directory location (especially for preamble-*.pch files)
https://bugs.llvm.org/show_bug.cgi?id=52505 Bug ID: 52505 Summary: Add libclang API to set temporary directory location (especially for preamble-*.pch files) Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: igor...@gmail.com CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk preamble-*.pch files generated by libclang can occupy a lot of disk space. So it is important for an IDE, which uses libclang, to prevent accumulation of these files after a crash. This can be done by setting libclang's temporary directory to a per-session value and removing this directory with all leftover files after a possible previous crash when the session starts. It is possible to configure clang's temporary directory location via platform-dependent environment variables (e.g. TMPDIR, TMP). Setting the environment variables works well if libclang lives in a separate process (e.g. in Qt Creator). But when libclang runs in the same process as the rest of the IDE (like in KDevelop), setting the environment variables is problematic, because they are inherited by the IDE's code and all child processes it spawns (compiler, build system and user-provided executables). The IDE must then remove the temporary directory environment variable from each child process where it can cause undesirable behavior. A libclang API function to configure the temporary directory location would greatly simplify cleanup implementation in this case. Here is the discussion of a rejected implementation of this feature in KDevelop: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/283. Related bug reports: Bug 52489, Bug 30673. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52506] New: llvm-nm tests are skipped if x86 is not in available targets
https://bugs.llvm.org/show_bug.cgi?id=52506 Bug ID: 52506 Summary: llvm-nm tests are skipped if x86 is not in available targets Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-nm Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org There is a spuriously-placed lit.local.cfg file at the top-level of the llvm-nm tests with the config equivalent of `REQUIRES: x86` in it. This means the tests will only run if x86 is in the supported target set. However, the top-level tests are not x86 specific, and there are also sub-folders which are e.g. ARM specific. It looks to me like this config file was just placed in the wrong place, and that it should be in the X86 subfolder (i.e. llvm/test/tools/llvm-nm/X86). When making this fix, we need to ensure there aren't any unexpected X86 dependencies in any of the other tests, by running the cmake, build and test sequence without the X86 target (perhaps with ARM instead). I've not got a non-x86 target cmake setup yet, but I'll take a look myself later today, if I get a chance. Not objecting if someone else has though and can do it quicker! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52507] New: Possible missing libm functions, ICE on reproducible
https://bugs.llvm.org/show_bug.cgi?id=52507
Bug ID: 52507
Summary: Possible missing libm functions, ICE on reproducible
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: jonathanchesterfi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Test case reported by Wael Elwasif,
#include
#include
#include
int main(int argc, char **argv){
float a = 1.5;
#pragma omp target map(tofrom: a)
{
a = floor(a);
}
printf("a = %lf\n", a);
}
Reported failure mode:
clang++ -std=c++17 -lm -O3 -fopenmp -target x86_64-pc-linux-gnu
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa
-march=gfx90a ./test_cmath.cpp
lld: error: undefined symbol: floorf
where changing the call to floorf, or the type to double, links OK.
However, on attempting to reproduce this, I get a segv on trunk:
https://godbolt.org/z/azsvd84fn
#3 0x558c2e2f6ff6 (anonymous
namespace)::AAKernelInfoFunction::changeToSPMDMode(llvm::Attributor&,
llvm::ChangeStatus&) (.constprop.1276) OpenMPOpt.cpp:0:0
#4 0x558c2e2f7de7 (anonymous
namespace)::AAKernelInfoFunction::manifest(llvm::Attributor&) OpenMPOpt.cpp:0:0
#5 0x558c2e22181c llvm::Attributor::manifestAttributes()
(/opt/compiler-explorer/clang-trunk-2025/bin/clang-14+0x2c2181c)
#6 0x558c2e22d61b llvm::Attributor::run()
(/opt/compiler-explorer/clang-trunk-2025/bin/clang-14+0x2c2d61b)
#7 0x558c2e300ec8 (anonymous namespace)::OpenMPOpt::runAttributor(bool)
(.part.1214) OpenMPOpt.cpp:0:0
#8 0x558c2e301531 (anonymous namespace)::OpenMPOpt::run(bool)
OpenMPOpt.cpp:0:0
#9 0x558c2e3044d7 llvm::OpenMPOptPass::run(llvm::Module&,
llvm::AnalysisManager&)
(/opt/compiler-explorer/clang-trunk-2025/bin/clang-14+0x2d044d7)
Bug was reported to me ~3 days ago.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51715] [AMDGPU][MC][GFX10] Incorrect FLAT GLOBAL fcmpswap data size
https://bugs.llvm.org/show_bug.cgi?id=51715 Dmitry Preobrazhensky changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||91f4650 Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52508] New: Templated lambdas crashing the complier
https://bugs.llvm.org/show_bug.cgi?id=52508
Bug ID: 52508
Summary: Templated lambdas crashing the complier
Product: clang
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: ogito12...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Here's some simplified code that exemplifies the problem.
int test(int x, int y)
{
auto test_lambda_impl2 = [&]()
{
if constexpr((f + z) < 3)
{
cout << f+z << endl;
}
};
auto test_lambda_impl1 = [&](int z)
{
switch(z)
{
case 0:
test_lambda_impl2.operator()();
break;
case 1:
test_lambda_impl2.operator()();
break;
case 2:
test_lambda_impl2.operator()();
break;
}
};
switch(x)
{
case 0:
test_lambda_impl1.operator()<0>(y);
break;
case 1:
test_lambda_impl1.operator()<1>(y);
break;
case 2:
test_lambda_impl1.operator()<2>(y);
break;
}
}
This just straight up crashes the compiler, if I remove test_lambda_impl2 and
just do something in test_lambda_impl1 instead, the code compiles but I get an
Invalid instruction exception or a segfault, depending on the code.
Clangd breaks when it has to parse this kind of code as well.
For reference, g++ works as expected.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52506] llvm-nm tests are skipped if x86 is not in available targets
https://bugs.llvm.org/show_bug.cgi?id=52506 James Henderson changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from James Henderson --- Fixed in 254aa65d048717ab93c3167364153298249432be. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52509] New: ThreadSanitizer: data race in std::__1::ios_base::width()
https://bugs.llvm.org/show_bug.cgi?id=52509
Bug ID: 52509
Summary: ThreadSanitizer: data race in
std::__1::ios_base::width()
Product: libc++
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mai...@live.de
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
I can reproduce with all versions of clang.
Steps to reproduce:
$ cat 1.cpp && clang++ -stdlib=libc++ -fsanitize=thread -std=c++20 1.cpp &&
./a.out
#include
#include
void Print() { std::cout << ""; }
int main() {
std::thread a{Print};
std::thread b{Print};
a.join();
b.join();
}
==
WARNING: ThreadSanitizer: data race (pid=4144)
Read of size 4 at 0x00500d28 by thread T2:
#0 std::__1::basic_ios >::fill() const
(a.out+0x4c301c)
#1 std::__1::basic_ostream >&
std::__1::__put_character_sequence
>(std::__1::basic_ostream >&, char const*,
unsigned long) (a.out+0x4c2956)
#2 std::__1::basic_ostream >&
std::__1::operator<<
>(std::__1::basic_ostream >&, char const*)
(a.out+0x4c256d)
#3 Print() (a.out+0x4c240f)
#4 decltype(static_cast(fp)()) std::__1::__invoke(void
(*&&)()) (a.out+0x4c46d2)
#5 void
std::__1::__thread_execute >, void
(*)()>(std::__1::tuple >, void (*)()>&,
std::__1::__tuple_indices<>) (a.out+0x4c4615)
#6 void*
std::__1::__thread_proxy >, void (*)()> >(void*)
(a.out+0x4c3cd2)
Previous write of size 4 at 0x00500d28 by thread T1:
#0 std::__1::basic_ios >::fill() const
(a.out+0x4c306a)
#1 std::__1::basic_ostream >&
std::__1::__put_character_sequence
>(std::__1::basic_ostream >&, char const*,
unsigned long) (a.out+0x4c2956)
#2 std::__1::basic_ostream >&
std::__1::operator<<
>(std::__1::basic_ostream >&, char const*)
(a.out+0x4c256d)
#3 Print() (a.out+0x4c240f)
#4 decltype(static_cast(fp)()) std::__1::__invoke(void
(*&&)()) (a.out+0x4c46d2)
#5 void
std::__1::__thread_execute >, void
(*)()>(std::__1::tuple >, void (*)()>&,
std::__1::__tuple_indices<>) (a.out+0x4c4615)
#6 void*
std::__1::__thread_proxy >, void (*)()> >(void*)
(a.out+0x4c3cd2)
Location is global 'std::__1::cout' of size 160 at 0x00500c90
(a.out+0x00500d28)
Thread T2 (tid=4147, running) created by main thread at:
#0 pthread_create (a.out+0x44c6cd)
#1 std::__1::__libcpp_thread_create(unsigned long*, void* (*)(void*),
void*) (a.out+0x4c3c49)
#2 std::__1::thread::thread(void (&)())
(a.out+0x4c26b0)
#3 main (a.out+0x4c2471)
Thread T1 (tid=4146, finished) created by main thread at:
#0 pthread_create (a.out+0x44c6cd)
#1 std::__1::__libcpp_thread_create(unsigned long*, void* (*)(void*),
void*) (a.out+0x4c3c49)
#2 std::__1::thread::thread(void (&)())
(a.out+0x4c26b0)
#3 main (a.out+0x4c245e)
SUMMARY: ThreadSanitizer: data race (/a.out+0x4c301c) in
std::__1::basic_ios >::fill() const
==
==
WARNING: ThreadSanitizer: data race (pid=4144)
Read of size 8 at 0x00500cb0 by thread T2:
#0 std::__1::ios_base::width() const (a.out+0x4c31bd)
#1 std::__1::ostreambuf_iterator >
std::__1::__pad_and_output
>(std::__1::ostreambuf_iterator >, char
const*, char const*, char const*, std::__1::ios_base&, char)
(a.out+0x4c2c83)
#2 std::__1::basic_ostream >&
std::__1::__put_character_sequence
>(std::__1::basic_ostream >&, char const*,
unsigned long) (a.out+0x4c298d)
#3 std::__1::basic_ostream >&
std::__1::operator<<
>(std::__1::basic_ostream >&, char const*)
(a.out+0x4c256d)
#4 Print() (a.out+0x4c240f)
#5 decltype(static_cast(fp)()) std::__1::__invoke(void
(*&&)()) (a.out+0x4c46d2)
#6 void
std::__1::__thread_execute >, void
(*)()>(std::__1::tuple >, void (*)()>&,
std::__1::__tuple_indices<>) (a.out+0x4c4615)
#7 void*
std::__1::__thread_proxy >, void (*)()> >(void*)
(a.out+0x4c3cd2)
Previous write of size 8 at 0x00500cb0 by thread T1:
#0 std::__1::ios_base::width(long) (a.out+0x4c33b6)
#1 std::__1::ostreambuf_iterator >
std::__1::__pad_and_output
>(std::__1::ostreambuf_iterator >, char
const*, char const*, char const*, std::__1::ios_base&, char)
(a.out+0x4c2e65)
#2 std::__1::basic_ostream >&
std::__1::__put_character_sequence
>(std::__1::basic_ostream >&, char const*,
unsigned long) (a.out+0x4c298d)
#3 std::__1::basic_ostream >&
std::__1::operator<<
>(std::__1::basic_ostream >&, char const*)
(a.out+0x4c256d)
#4 Print() (a.out+0x4c240f)
#5 decltype(static_cast(fp)()) std::__1::__invoke(void
(*&&)()) (a.out+0x4c46d2)
#6 void
std::__1::__thread_execute >, void
(*)()>(std::__1::tuple >, void (*)()>&,
std::__1::__tuple_indices<>) (a.out+0x4c4615)
#7 void*
std::__1::__thread_proxy >, void (*)()> >(void*)
(a.out+0x4c3cd2)
Location is global 'std::__1::cout' of
[llvm-bugs] [Bug 52510] New: Load address range overlap reported when ALIGN is used with LMA and VMA regions
https://bugs.llvm.org/show_bug.cgi?id=52510
Bug ID: 52510
Summary: Load address range overlap reported when ALIGN is used
with LMA and VMA regions
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: konstantin.schw...@hightec-rt.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
In the example shown below, the following error is reported:
ld.lld: error: section .data3 load address range overlaps with .data
>>> .data3 range is [0x805, 0x80C]
>>> .data range is [0x808, 0x80B]
linkerscript:
```
MEMORY
{
CODE (rx) : ORIGIN = 0x0800, LENGTH = 512K
DATA (rw) : ORIGIN = 0x2400, LENGTH = 95K
}
SECTIONS
{
.text :
{
*(.text)
} > CODE
.data : ALIGN(8)
{
. += 4;
} > DATA AT> CODE
/* This section is needed to get a new program header created for .data3 */
.data2 :
{
. += 8;
} > DATA
.data3 :
{
. += 8;
} > DATA AT> CODE
}
```
source file:
```
.text
.globl _start
_start:
nop
```
Looking at the ELF that we get when using `--no-check-sections`, we find the
following program headers:
```
Program Headers:
Type Offset VirtAddr PhysAddr
FileSizMemSiz Flags Align
LOAD 0x1000 0x0800 0x0800
0x0001 0x0001 R E0x1000
LOAD 0x1400 0x2400 0x0808
0x0004 0x0004 R E0x1000
LOAD 0x1404 0x2404 0x2404
0x0008 0x0008 R E0x1000
LOAD 0x140c 0x240c 0x0805
0x0008 0x0008 R E0x1000
```
, indicating that .data3 is not aware of the alignment requirement of .data
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 41046 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: Val.getType()->isSized() && "Don't know how to create an empty vreg"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-11-15 Type: Bug New issue 41046 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: Val.getType()->isSized() && "Don't know how to create an empty vreg" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41046 Detailed Report: https://oss-fuzz.com/testcase?key=6750277756125184 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Val.getType()->isSized() && "Don't know how to create an empty vreg" llvm::IRTranslator::getOrCreateVRegs llvm::IRTranslator::translateCallBase Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201906300300:201910150335 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6750277756125184 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 52511] New: [amdgpu] const globals incorrectly marked addrspace(4)
https://bugs.llvm.org/show_bug.cgi?id=52511
Bug ID: 52511
Summary: [amdgpu] const globals incorrectly marked addrspace(4)
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: jonathanchesterfi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Given
#include
#include
#include
#pragma omp declare target
static const double smallx = 1.0e-5;
static const double log_smallx = log(smallx);
#pragma omp end declare target
clang++ -O2 -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa math_exp.cpp -o
math_exp -lm -save-temps
unhandled address space
UNREACHABLE executed at
/home/amd/llvm-project/llvm/lib/Target/AMDGPU/SIISelLowering.cpp:8869!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
IR emitted from clang with -disable-llvm-passes contains a global constructor
to do the log call,
define internal void @__omp_offloading__10303_4068b_log_smallx_l9_ctor() #4 {
entry:
%call = call double @"_ZL28log$ompvariant$S2$s7$Pamdgcnd"(double
1.00e-05) #17
store double %call, double addrspace(4)* @_ZL10log_smallx, align 8, !tbaa !9
ret void
}
The backend (probably rightly) chokes on that, addrspace(4) is constant in the
sense that the value has to be set before kernel execution begins.
The optimal codegen, I think, would look like a global ctor that writes to that
value as an addrspace(1) value, then the other kernels load it as an
addrspace(4) value. Thus we can use scalar loads on it, after the global ctor
ran to initialise it.
A less clever way to fix this ICE is to find the point in clang that tags the
const variable as addrspace(4) and back it off to only do so when the
initialiser is already available as a constant.
I think this is an artefact of how constexpr is handled by target regions - I
suspect log is marked constexpr in a glibc header, but it isn't actually
constexpr in the hip math headers - but have not confirmed that theory.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52504] Assertion `(!From->hasAnyUseOfValue(i) || From->getValueType(i) == To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!"
https://bugs.llvm.org/show_bug.cgi?id=52504 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||5be64d416481 6efe64cf9f11 ||3d01507c2dec Resolution|--- |FIXED --- Comment #5 from Sanjay Patel --- The original commit was reverted: https://reviews.llvm.org/rG5be64d416481 I added a minimized crasher test based on the example here and a fixed version of the patch with: https://reviews.llvm.org/rG6efe64cf9f11 https://reviews.llvm.org/rG3d01507c2dec -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51794] [LoopVectorizer] Suspected wrong code at -Os
https://bugs.llvm.org/show_bug.cgi?id=51794 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||112c1c346a61 Status|NEW |RESOLVED --- Comment #6 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rG112c1c346a61 It would be great if you could verify the fix and re-open the bug if it still reproduces. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52485] wrong code at -Os on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=52485 Florian Hahn changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||112c1c346a61 Resolution|--- |FIXED --- Comment #5 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rG112c1c346a61 It would be great if you could verify the fix and re-open the bug if it still reproduces. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52512] New: llvm-c++filt unable to demangle void f()
https://bugs.llvm.org/show_bug.cgi?id=52512
Bug ID: 52512
Summary: llvm-c++filt unable to demangle void
f()
Product: tools
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: llvm-c++filt
Assignee: unassignedb...@nondot.org
Reporter: gbrey...@gmail.com
CC: llvm-bugs@lists.llvm.org
When attempting to demangle "_Z1fIDnLDn0EEvv" llvm-cxxfilt does not demangle
the input. According to GCC we should see similar to "void f()"
This was found by compiling the following:
template void f() {}
typedef decltype(nullptr) nullptr_t;
template <> void f() {}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41039] instcombine incorrectly removes "dead" malloc/operator delete pair
https://bugs.llvm.org/show_bug.cgi?id=41039 Yuanfang Chen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Yuanfang Chen --- *** This bug has been marked as a duplicate of bug 49022 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52390] clang -O2 BPF netd.o failed to boot on some Android devices
https://bugs.llvm.org/show_bug.cgi?id=52390 Chih-Hung Hsieh changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #13 from Chih-Hung Hsieh --- Yonghong, Thanks for looking into the llvm code. The root failure was found to be in older Android BPF verifier, which does not track value ranges of variables on the stack. New llvm output code now returns one variable in netd.c directly from stack. The BPF verifier cannot be certain that the return value is always 0 or 1, and aborted the normal boot process. Since we need to load new netd.o to existing Adroid devices, so the solution now is to modify netd.c and make sure that the return value is always 0 or 1. There is no need to change clang/llvm for now. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52515] New: Loop Vectorizer triggers an assert "IsOrdered requires IsInLoop"
https://bugs.llvm.org/show_bug.cgi?id=52515
Bug ID: 52515
Summary: Loop Vectorizer triggers an assert "IsOrdered requires
IsInLoop"
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: serguei.kat...@azul.com
CC: llvm-bugs@lists.llvm.org
For the following reduced test case
===
; ModuleID = 'bad.ll'
source_filename = "bad.ll"
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-none-linux-gnu"
define float @wombat() {
bb:
br label %bb1
bb1: ; preds = %bb9, %bb
%tmp = phi i64 [ 0, %bb ], [ %tmp10, %bb9 ]
%tmp2 = phi float [ 0.00e+00, %bb ], [ %tmp4, %bb9 ]
%tmp3 = phi i64 [ 0, %bb ], [ %tmp5, %bb9 ]
%tmp4 = fadd float %tmp2, 1.00e+00
%tmp5 = add nsw i64 %tmp3, 1
%tmp6 = icmp ult i64 %tmp, 65536
br i1 %tmp6, label %bb9, label %bb7
bb7: ; preds = %bb1
%tmp8 = phi float [ %tmp4, %bb1 ]
ret float %tmp8
bb9: ; preds = %bb1
%tmp10 = add nuw nsw i64 %tmp, 1
br i1 false, label %bb11, label %bb1
bb11: ; preds = %bb9
%tmp12 = phi float [ %tmp4, %bb9 ]
ret float %tmp12
}
!0 = !{!"function_entry_count", i64 32768}
===
the following assert is triggered.
===
> opt -passes=loop-vectorize -S bad.ll
opt:
/localhome/skatkov/work/llvm/src/llvm/lib/Transforms/Vectorize/VPlan.h:1186:
llvm::VPReductionPHIRecipe::VPReductionPHIRecipe(llvm::PHINode*,
llvm::RecurrenceDescriptor&, llvm::VPValue&, bool, bool): Assertion
`(!IsOrdered || IsInLoop) && "IsOrdered requires IsInLoop"' failed.
===
The current processing phi node is
%tmp2 = phi float [ 0.00e+00, %bb ], [ %tmp4, %bb9 ]
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50312] llvm-objdump crash when disassemble a webassembly file which incudling bytecode "unreachable"
https://bugs.llvm.org/show_bug.cgi?id=50312 Wouter van Oortmerssen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52516] New: [M68k] Code selection failed with string length greater than or equal to 4
https://bugs.llvm.org/show_bug.cgi?id=52516
Bug ID: 52516
Summary: [M68k] Code selection failed with string length
greater than or equal to 4
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: M68k
Assignee: unassignedb...@nondot.org
Reporter: t104360...@ntut.org.tw
CC: glaub...@physik.fu-berlin.de,
llvm-bugs@lists.llvm.org, miny...@uci.edu
Created attachment 25450
--> https://bugs.llvm.org/attachment.cgi?id=25450&action=edit
Preprocessed source
This is the code that triggered this error:
void test(char *s)
{
}
int main()
{
char s[] = "123";
test(s);
return 0;
}
This is the error message:
$ clang -ccc-gcc-name linux-gnu-gcc --target=m68k tmp.c -o tmp
fatal error: error in backend: Cannot select: t47: i32,ch =
load<(dereferenceable load (s8) from `i8* getelementptr inbounds ([4 x i8], [4
x i8]* @__const.main.s, i32 0, i32 0)` + 1), zext from i8> t4, t46, undef:i32
t46: i32 = add nuw t34, Constant:i32<1>
t34: i32 = M68kISD::WrapperPC TargetGlobalAddress:i32<[4 x i8]*
@__const.main.s> 0
t33: i32 = TargetGlobalAddress<[4 x i8]* @__const.main.s> 0
t36: i32 = Constant<1>
t3: i32 = undef
In function: main
clang-14: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
7f7cab6bb1d48b53e1fa9ab5a4fd7bcf7f00f19b)
Target: m68k
Thread model: posix
InstalledDir: /home/sheng/project/compiler/llvm_m68k/build/bin
clang-14: note: diagnostic msg:
---
Here's my environment:
$ clang-v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
7f7cab6bb1d48b53e1fa9ab5a4fd7bcf7f00f19b)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/sheng/project/compiler/llvm_m68k/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Selected multilib: .;@m64
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50568] [Format] star/amp is incorrectly recognized as PointerOrReference when overloaded operator is called as a member function
https://bugs.llvm.org/show_bug.cgi?id=50568 Yilong Guo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||rG873308fd8c96a54f002425142 ||5daac1b78f70119 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
