[llvm-bugs] [Bug 52359] New: ICE: __builtin_mul_overflow breaks on (__int128)1 * -1 -> __uint128
https://bugs.llvm.org/show_bug.cgi?id=52359
Bug ID: 52359
Summary: ICE: __builtin_mul_overflow breaks on (__int128)1 * -1
-> __uint128
Product: clang
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: kamilcukrow...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 25404
--> https://bugs.llvm.org/attachment.cgi?id=25404&action=edit
bugpoint-reduced-simplified.bc
The following source file:
```
int main() {
__uint128_t r;
__builtin_mul_overflow((__int128)-1, 1, &r);
}
```
results in:
```
$ clang input.c
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/bin/clang-12 -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name input.c -mrelocation-model pic -pic-level
2 -pic-is-pie -mframe-pointer=all -fmath-errno -fno-rounding-math
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic
-fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir
/usr/lib/clang/12.0.1 -internal-isystem /usr/local/include -internal-isystem
/usr/lib/clang/12.0.1/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdebug-compilation-dir /tmp
-ferror-limit 19 -stack-protector 2 -fgnuc-version=4.2.1 -fcolor-diagnostics
-faddrsig -o /tmp/input-b9d941.o -x c input.c
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'input.c'.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
#0 0x7f0422420793 (/usr/bin/../lib/libLLVM-12.so+0xb49793)
#1 0x7f042241de96 (/usr/bin/../lib/libLLVM-12.so+0xb46e96)
#2 0x7f0421531da0 __restore_rt (/usr/bin/../lib/libc.so.6+0x3cda0)
#3 0x7f0421531d22 raise (/usr/bin/../lib/libc.so.6+0x3cd22)
#4 0x7f042151b862 abort (/usr/bin/../lib/libc.so.6+0x26862)
#5 0x7f042175a802 __gnu_cxx::__verbose_terminate_handler() (.cold)
/build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:75:10
#6 0x7f0421766c8a __cxxabiv1::__terminate(void (*)())
/build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48:15
#7 0x7f0421766cf7 (/usr/bin/../lib/libstdc++.so.6+0xa5cf7)
#8 0x7f0421766f8e (/usr/bin/../lib/libstdc++.so.6+0xa5f8e)
#9 0x7f042175d36c std::__throw_logic_error(char const*)
/build/gcc/src/gcc/libstdc++-v3/src/c++11/functexcept.cc:70:5
#10 0x7f0422d167c7 llvm::SelectionDAG::getTargetExternalSymbol(char const*,
llvm::EVT, unsigned int) (/usr/bin/../lib/libLLVM-12.so+0x143f7c7)
#11 0x7f04252d44a1 (/usr/bin/../lib/libLLVM-12.so+0x39fd4a1)
#12 0x7f042538a297 (/usr/bin/../lib/libLLVM-12.so+0x3ab3297)
#13 0x7f0422c904de
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
const (/usr/bin/../lib/libLLVM-12.so+0x13b94de)
#14 0x7f0422bf5e4d (/usr/bin/../lib/libLLVM-12.so+0x131ee4d)
#15 0x7f0422c0973d (/usr/bin/../lib/libLLVM-12.so+0x133273d)
#16 0x7f0422c5 (/usr/bin/../lib/libLLVM-12.so+0x133a115)
#17 0x7f0422c11901 llvm::SelectionDAG::LegalizeTypes()
(/usr/bin/../lib/libLLVM-12.so+0x133a901)
#18 0x7f0422d2c216 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/usr/bin/../lib/libLLVM-12.so+0x1455216)
#19 0x7f0422d2f082
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/usr/bin/../lib/libLLVM-12.so+0x1458082)
#20 0x7f0422d318d9 (/usr/bin/../lib/libLLVM-12.so+0x145a8d9)
#21 0x7f042525338c (/usr/bin/../lib/libLLVM-12.so+0x397c38c)
#22 0x7f04228192a9
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/bin/../lib/libLLVM-12.so+0xf422a9)
#23 0x7f042257caf0 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/bin/../lib/libLLVM-12.so+0xca5af0)
#24 0x7f042257cc5c llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/bin/../lib/libLLVM-12.so+0xca5c5c)
#25 0x7f042257e47a llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/bin/../lib/libLLVM-12.so+0xca747a)
#26 0x7f042941a193 (/usr/bin/../lib/libclang-cpp.so.12+0x1898193)
#27 0x7f042941c055 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/usr/bin/../lib/libclang-cpp.so.12+0x189a055)
#28 0x7f0429799652 (/usr/bin/../lib/libclang-cpp.so.12+0x1c17652)
#29 0x7f04284b9669 cl
[llvm-bugs] [Bug 52360] New: __PRETTY_FUNCTION__ leaks absolute paths even with -fmacro-prefix-map
https://bugs.llvm.org/show_bug.cgi?id=52360
Bug ID: 52360
Summary: __PRETTY_FUNCTION__ leaks absolute paths even with
-fmacro-prefix-map
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: vesko.karaga...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
The `-fmacro-prefix-map` option remaps "file source paths in predefined
preprocessor macros and __builtin_FILE()". The __PRETTY_FUNCTION__ predefined
macro expands to a string, which can contain absolute file paths when the
function signature includes a lambda as a template parameter.
```cpp
template
void a() {
const char* file = __FILE__;
const char* func = __PRETTY_FUNCTION__;
}
int main() {
auto f = []() { return 0; };
a();
}
```
When the above code is compiled with `-fmacro-prefix-map=$SRCDIR=/TEST`, the
paths in the expansion of `__PRETTY_FUNCTION__` are not remapped.
The output binary contains:
```
void a() [F = (lambda at /app/example.cpp:8:14)]
```
Compiler Explorer: https://godbolt.org/z/8vYW84oMv
--
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 52361] New: wrong code at -O2 code on MacOSX with clang 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=52361
Bug ID: 52361
Summary: wrong code at -O2 code on MacOSX with clang 13.0.0
Product: clang
Version: 13.0
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: khar...@mathworks.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 25405
--> https://bugs.llvm.org/attachment.cgi?id=25405&action=edit
source code and run script to demonstate this problem.
See code below,
At -O2 optimization, it appears that clang boils away the "else" path in the
"bool test(const Name& name)" routine below - based only on a slight variation
in the anatomy of the structure (i.e. adding the "long t" field).
Initially, we discovered and reproduced this with Apple's Xcode 13. We then
obtained clang 13.0.0 directly from llvm.org and reproduced identical results.
The attached reproduction contains the source and script for three test
scenarios.
The first demonstrates expected behavior (no optimization).
The second demonstrates expected behavior with -O2 optimization.
The third demonstrates the unexpected behavior triggered by the addition of
"long t;" to the structure.
Thank you very much for looking into this!
REPRO CODE:
#include
#include
struct Name
{
char j[32];
#if EXPOSEBUG
long t;
#endif
};
bool test(const Name& name)
{
if (0 == ((uint64_t) &name & 2)) {
return 0;
} else {
return 1;
}
}
int main()
{
Name myname;
bool r = test(myname);
printf("NORMAL CASE :%s\n", r ? "!!!WRONG!!!" : "CORRECT");
const Name *px = (const Name *) 0x1e2;
r = test(*px);
printf("SPECIAL CASE:%s\n", r ? "CORRECT" : "!!!WRONG!!!");
return 0;
}
--
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 52361] wrong code at -O2 code on MacOSX with clang 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=52361 Roman Lebedev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||lebedev...@gmail.com --- Comment #1 from Roman Lebedev --- This looks like UB to me. https://godbolt.org/z/5M4eP8h36 /app/example.cpp:28:18: runtime error: reference binding to misaligned address 0x01e2 for type 'const Name', which requires 8 byte alignment 0x01e2: note: pointer points here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:28:18 in -- 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 52362] New: debugserver: ignores P packets when setting AVX-2 and AVX-512 registers
https://bugs.llvm.org/show_bug.cgi?id=52362 Bug ID: 52362 Summary: debugserver: ignores P packets when setting AVX-2 and AVX-512 registers Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: alessandro.arzi...@gmail.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Sending a P packet to debugserver to change the value of a AVX-2 or AVX-512 register will appear to work: request: $P5b=cdcc0840;thread:39d025;#24 response: $OK#00 but the new register value will not be written to the target process. This happens because DNBArchImplX86_64::SetRegisterValue at line 2635: https://github.com/llvm/llvm-project/blob/2c4a9e830cbb3b91a57902f7ecd508c544701819/lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp#L2635 returns directly instead of setting success to true and allowing the call to SetRegisterState to happen. -- 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 52363] New: case where llc crashes when DWARF are generated
https://bugs.llvm.org/show_bug.cgi?id=52363
Bug ID: 52363
Summary: case where llc crashes when DWARF are generated
Product: new-bugs
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: b2.t...@gmx.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
the test case is reduced from the source language side to produce this ll file:
di_bug.ll:
---
; ModuleID = 'di_bug'
source_filename = "di_bug"
; Function Attrs: noinline
define i32 @main() #0 !dbg !7 {
entry:
call void @di_bug.takeFun(void (i32)* @di_bug.main.27.__tmp0), !dbg !13
ret i32 0, !dbg !14
}
; Function Attrs: noinline
define void @di_bug.takeFun(void (i32)* %0) #0 !dbg !15 {
entry:
%1 = alloca void (i32)*, align 8
store void (i32)* %0, void (i32)** %1, align 8
call void @llvm.dbg.declare(metadata void (i32)** %1, metadata !20, metadata
!DIExpression()), !dbg !21
ret void, !dbg !22
}
; Function Attrs: nounwind readnone speculatable willreturn
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
; Function Attrs: noinline
define void @di_bug.main.27.__tmp0(i32 %0) #0 !dbg !24 {
entry:
%1 = alloca i32, align 4
store i32 %0, i32* %1, align 4
call void @llvm.dbg.declare(metadata i32* %1, metadata !26, metadata
!DIExpression()), !dbg !27
ret void, !dbg !28
}
attributes #0 = { noinline }
attributes #1 = { nounwind readnone speculatable willreturn }
!llvm.module.flags = !{!0, !1}
!llvm.dbg.cu = !{!2}
!0 = !{i32 2, !"Dwarf Version", i32 2}
!1 = !{i32 2, !"Debug Info Version", i32 3}
!2 = distinct !DICompileUnit(language: DW_LANG_C, file: !3, producer: "0.0.0",
isOptimized: false, runtimeVersion: 0, splitDebugFilename: "temp.txt",
emissionKind: FullDebug, enums: !4, splitDebugInlining: false)
!3 = !DIFile(filename: "di_bug.sx", directory: "/home//Desktop/temp")
!4 = !{!5}
!5 = !DICompositeType(tag: DW_TAG_enumeration_type, name: "E", scope: !6, file:
!3, baseType: !10, size: 32, elements: !11)
!6 = distinct !DILexicalBlock(scope: !7, file: !3, line: 11, column: 5)
!7 = distinct !DISubprogram(name: "main", linkageName: "main", scope: !3, file:
!3, line: 8, type: !8, scopeLine: 8, flags: DIFlagPrototyped, spFlags:
DISPFlagLocalToUnit | DISPFlagDefinition, unit: !2, retainedNodes: !9)
!8 = !DISubroutineType(types: !9)
!9 = !{}
!10 = !DIBasicType(name: "u32", size: 32, encoding: DW_ATE_unsigned)
!11 = !{!12}
!12 = !DIEnumerator(name: "e", value: 0)
!13 = !DILocation(line: 11, column: 12, scope: !6)
!14 = !DILocation(line: 12, column: 5, scope: !6)
!15 = distinct !DISubprogram(name: "di_bug.takeFun", linkageName:
"di_bug.takeFun", scope: !3, file: !3, line: 19, type: !16, scopeLine: 19,
flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition,
unit: !2, retainedNodes: !9)
!16 = !DISubroutineType(types: !17)
!17 = !{!18}
!18 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "static function (E e)*",
baseType: !19, size: 64, align: 8, dwarfAddressSpace: 0)
!19 = !DIBasicType(tag: DW_TAG_unspecified_type, name: "static function (E e)")
!20 = !DILocalVariable(name: "afun", arg: 1, scope: !15, file: !3, line: 19,
type: !18)
!21 = !DILocation(line: 19, column: 18, scope: !15)
!22 = !DILocation(line: 21, column: 1, scope: !23)
!23 = distinct !DILexicalBlock(scope: !15, file: !3, line: 21, column: 1)
!24 = distinct !DISubprogram(name: "di_bug.main.27.__tmp0", linkageName:
"di_bug.main.27.__tmp0", scope: !3, file: !3, line: 11, type: !25, scopeLine:
11, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition,
unit: !2, retainedNodes: !9)
!25 = !DISubroutineType(types: !4)
!26 = !DILocalVariable(name: "e", arg: 1, scope: !24, file: !3, line: 11, type:
!5)
!27 = !DILocation(line: 11, column: 24, scope: !24)
!28 = !DILocation(line: 11, column: 34, scope: !29)
!29 = distinct !DILexicalBlock(scope: !24, file: !3, line: 11, column: 34)
---
If i feed LLC with that IR then it crashes
```bash
$ llc di_bug.ll
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: /usr/bin/llc --filetype=obj --relocation-model=pic
--mtriple=x86_64 -O0
#0 0x7f848223527a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/lib64/libLLVM-11.so+0xa8b27a)
#1 0x7f84822334e4 llvm::sys::RunSignalHandlers()
(/lib64/libLLVM-11.so+0xa894e4)
#2 0x7f8482233676 (/lib64/libLLVM-11.so+0xa89676)
#3 0x7f8481434a70 __restore_rt (/lib64/libc.so.6+0x3da70)
#4 0x7f84829a7f40 llvm::DIE::getUnitDie() const
(/lib64/libLLVM-11.so+0x11fdf40)
#5 0x7f84829a7f99 llvm::DIE::getUnit() const
(/lib64/libLLVM-11.so+0x11fdf99)
#6 0x7f84829e10f7 llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*)
(/lib64/libLLVM-11.so+0x12370f7)
#7 0x7f84829d4588 llvm::DwarfDebug::beginModule()
(/lib64/libLLVM-11.so+0x122a
[llvm-bugs] [Bug 52364] New: code coverage ignores lines after assert(...)
https://bugs.llvm.org/show_bug.cgi?id=52364
Bug ID: 52364
Summary: code coverage ignores lines after assert(...)
Product: clang
Version: 13.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: m...@hanicka.net
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Created attachment 25406
--> https://bugs.llvm.org/attachment.cgi?id=25406&action=edit
minimal example
Hi I noticed an error in clang-13 code coverage reporting.
If you follow these steps:
```
clang test.c -fprofile-instr-generate -fcoverage-mapping -g -O0 -DDEBUG -o test
./test
llvm-profdata merge -sparse ./default.profraw -o ./test.profdata
llvm-cov show ./test -instr-profile=./test.profdata
```
The resulting coverage report is:
```
1| |#include
2| |#include
3| |
4| 1|int main() {
5| 1| assert(1);
6| 0| puts("not covered"); // line after assert is not covered
7| 1| puts("covered");
8| 1| assert(1);
9| 0| puts("not covered"); // line after assert is not covered
10| 1| assert(1);
11| 0| assert(1); // line after assert is not covered
12| 0| puts("not covered"); // line after assert is not covered
13| 1|}
```
as you can see all lines after an `assert(...)` are ignored, this is a
regression as clang-12 doesn't have this behaviour
--
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 52365] New: missed optimization for the sum of two numbers
https://bugs.llvm.org/show_bug.cgi?id=52365
Bug ID: 52365
Summary: missed optimization for the sum of two numbers
Product: clang
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: dushis...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
For such simple function:
int32_t f(int32_t & __restrict a, const int32_t & __restrict b) {
a += b + 17;
return a + b;
}
clang (12/13) produces (-O3) such assembly (amd64):
mov eax, dword ptr [rsi]
mov ecx, dword ptr [rdi]
lea edx, [rax + rcx]
add ecx, eax
add ecx, 17
mov dword ptr [rdi], ecx
add eax, edx
add eax, 17
ret
while gcc producues:
mov eax, DWORD PTR [rsi]
mov edx, DWORD PTR [rdi]
lea edx, [rax+17+rdx]
mov DWORD PTR [rdi], edx
add eax, edx
ret
even without benchmark (which show that gcc's variant wins)
you can see that for some reason clang forgot that in "ecx"
has "a + b + 17", so it can just add it to eax and that's all.
But for some reason it recalculate expression again via:
add eax, edx
add eax, 17
--
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 40440 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Preprocessor::CachingLex
Updates: Status: WontFix Comment #1 on issue 40440 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Preprocessor::CachingLex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40440#c1 ClusterFuzz testcase 5309730508111872 is closed as invalid, so closing issue. -- 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 52366] New: Wrong processing of substitution failure in an atomic constraint of template function requires-clause
https://bugs.llvm.org/show_bug.cgi?id=52366
Bug ID: 52366
Summary: Wrong processing of substitution failure in an atomic
constraint of template function requires-clause
Product: clang
Version: 13.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: fchelno...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Below code is valid, because sizeof(int)>0:
```
template
void g() requires(sizeof(T)>0 || sizeof(U)>0) {}
int main() {
g(); //error in Clang
}
```
It is accepted by GCC, but unfortunately not by Clang. Demo:
https://gcc.godbolt.org/z/P69beYhqY
Related discussion: https://stackoverflow.com/q/69173117/7325599
--
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 52367] New: Clang segfaults when compiling protobuf for mips
https://bugs.llvm.org/show_bug.cgi?id=52367 Bug ID: 52367 Summary: Clang segfaults when compiling protobuf for mips Product: clang Version: 13.0 Hardware: SGI OS: Linux Status: NEW Severity: release blocker Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: raj.k...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 25407 --> https://bugs.llvm.org/attachment.cgi?id=25407&action=edit test case attached testcase causes clang to sigsegv fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: mips-yoe-linux-musl-clang++ -target mips-yoe-linux-musl -mabi=32 -mhard-float -march=mips32r2 -mbig-endian -Qunused-arguments -fs tack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-lin ux-musl/protobuf/3.19.0-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I.. -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -O2 -pipe -g -feliminate- unused-debug-types -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/protobuf/3.19.0-r0=/usr/src/debug/protobuf/3.19.0-r0 -fdebug- prefix-map=/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/protobuf/3.19.0-r0=/usr/src/debug/protobuf/3.19.0-r0 -fdebug-prefix-map=/mnt/b/yoe/maste r/build/tmp/work/mips32r2-yoe-linux-musl/protobuf/3.19.0-r0/recipe-sysroot= -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/prot obuf/3.19.0-r0/recipe-sysroot-native= -fvisibility-inlines-hidden -c google/protobuf/generated_message_tctable_lite.cc -fPIC -DPIC -o google/protobuf/.libs/ generated_message_tctable_lite.o 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'google/protobuf/generated_message_tctable_lite.cc'. 4. Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@_ZN6google8protobuf8internal8TcParser13SingularFixedIyhEEPKcPNS0_11MessageL iteES5_PNS1_12ParseContextEPKNS1_16TcParseTableBaseEyNS1_11TcFieldDataE' 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): clang-13: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 13.0.0 (https://github.com/llvm/llvm-project d7b669b3a30345cfcdb2fde2af6f48aa4b94845d) Target: mips-yoe-linux-musl -- 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 52246] -ObjC and -all_load should not apply to LC_LINKER_OPTION libraries
https://bugs.llvm.org/show_bug.cgi?id=52246 Jez Ng changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||https://github.com/llvm/llv ||m-project/commit/6c2f26a159 ||ec0a68d16424cc8aadd8801c7ef ||31d 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 51146] Support common symbols in LTO
https://bugs.llvm.org/show_bug.cgi?id=51146 Jez Ng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||https://reviews.llvm.org/rG ||e49374f9e0c02dae575f26f9696 ||77534b94eac3d -- 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 52368] New: Class template argument deduction fails in case of function type argument
https://bugs.llvm.org/show_bug.cgi?id=52368
Bug ID: 52368
Summary: Class template argument deduction fails in case of
function type argument
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: fchelno...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
In the following program Clang is unable to perform class template argument
deduction:
```
template
struct A{
A(T f()){ f(); }
};
int foo() { return 1; }
int main() {
[[maybe_unused]] A y = foo; // Clang error
}
```
GCC accepts it successfully, demo: https://gcc.godbolt.org/z/PKe6T5aW5
Related discussion: https://stackoverflow.com/q/69778510/7325599
--
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
