[llvm-bugs] [Bug 50178] New: Introduction of -fbracket-depth broke std::array:s longer than 256
https://bugs.llvm.org/show_bug.cgi?id=50178
Bug ID: 50178
Summary: Introduction of -fbracket-depth broke std::array:s
longer than 256
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: we...@wsoptics.de
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The code at the bottom behaves like this with clang-12:
% clang++ -std=c++17 -c b.cpp
In file included from b.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include/g++-v10/array:245:52: fatal
error: instantiating fold expression with 257 arguments exceeded expression
nesting limit of 256
-> array && ...), _Tp>,
^~~~
b.cpp:6:12: note: while substituting deduced template arguments into function
template '' [with _Tp = S, _Up = ]
std::array a{S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{},
^
1 error generated.
% clang++ -std=c++17 -c -fbracket-depth=512 b.cpp
% echo $?
0
This actually hit our production code and took me a while to reduce. I think
limiting the length of std::array to <= 256 by default is not desirable.
This is the code:
#include
struct S {};
std::array a{S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{}, S{},
S{}};
--
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 50179] New: clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:596: clang::ento::loc::MemRegionVal::MemRegionVal(const clang::ento::MemRegion *): Assertion `r' failed.
https://bugs.llvm.org/show_bug.cgi?id=50179
Bug ID: 50179
Summary: clang/include/clang/StaticAnalyzer/Core/PathSensitive/
SVals.h:596:
clang::ento::loc::MemRegionVal::MemRegionVal(const
clang::ento::MemRegion *): Assertion `r' failed.
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: vince.a.bridg...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
This crash seems to have been introduced by
https://bugs.llvm.org/show_bug.cgi?id=49007.
Trimmed crash ...
$ clang --analyze case.c
clang: clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:596:
clang::ento::loc::MemRegionVal::MemRegionVal(const clang::ento::MemRegion *):
Assertion `r' failed.
Stack dump:
0. Program arguments: clang --analyze case.c
1. parser at end of file
2. While analyzing stack:
#0 Calling getTaskJob
3. case.c:12:17: Error evaluating statement
4. case.c:12:17: Error evaluating statement
#11 0x077ae64c
clang::ento::loc::MemRegionVal::MemRegionVal(clang::ento::MemRegion const*)
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:597:3
#12 0x082e2f7a
clang::ento::SValBuilder::evalCastSubKind(clang::ento::loc::MemRegionVal,
clang::QualType, clang::QualType)
clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:773:18
#13 0x082e228f clang::ento::SValBuilder::evalCastKind(clang::ento::Loc,
clang::QualType, clang::QualType)
clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:612:12
#14 0x082dfb4c clang::ento::SValBuilder::evalCast(clang::ento::SVal,
clang::QualType, clang::QualType)
clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:587:12
#15 0x082a2b48 (anonymous
namespace)::RegionStoreManager::getBinding((anonymous
namespace)::RegionBindingsRef const&, clang::ento::Loc, clang::QualType)
clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1510:24
reproducer ...
clang --analyze case.c
typedef struct taskS {
void * pJob;
} taskS;
typedef struct workS {
taskS * pTaskList;
} workS;
void * getTaskJob ( unsigned jobId , workS *pWork, unsigned taskId)
{
const taskS * pTask = pWork->pTaskList + taskId;
taskS task = *pTask;
return task.pJob;
}
anticipated fix (to be submitted)
@@ -761,8 +761,8 @@ SVal SValBuilder::evalCastSubKind(loc::MemRegionVal V,
QualType CastTy,
// Next fixes pointer dereference using type different from its initial
// one. See PR37503 and PR49007 for details.
if (const auto *ER = dyn_cast(R)) {
-R = StateMgr.getStoreManager().castRegion(ER, CastTy);
-return loc::MemRegionVal(R);
+if ((R = StateMgr.getStoreManager().castRegion(ER, CastTy)))
+ return loc::MemRegionVal(R);
}
--
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 50180] New: ObjFile feels a bit overtemplatized
https://bugs.llvm.org/show_bug.cgi?id=50180 Bug ID: 50180 Summary: ObjFile feels a bit overtemplatized Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com These methods in InputFiles.cpp are templatized on LP: getPlatformInfo() ObjFile::parse() DylibFile::parse() They use the template parameter to pick either mach_header or mach_header_64. mach_header and mach_header_64 are the same except that the latter is one word larger. I think the template here is mostly unnecessary. For reading fields of mach_header / mach_header_64 , we can use mach_header for both file formats since the fields actually carrying data are the same. For getting the offset in findCommand<>(), instead of const uint8_t *p = reinterpret_cast(hdr) + sizeof(Header); we could do const uint8_t *p = reinterpret_cast(hdr); if (reinterpret_cast(hdr)->magic == MH_MAGIC_64 || reinterpret_cast(hdr)->magic == MH_CIGAM_64) p += sizeof(mach_header_64); else p += sizeof(mach_header); (...which could be a method on InputFile). Not super important, but it would've been a bit easier to read and understand to me at least :) -- 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 50181] New: const clang::ArrayType *clang::Type::castAsArrayTypeUnsafe() const: Assertion `isa(CanonicalType)' failed.
https://bugs.llvm.org/show_bug.cgi?id=50181
Bug ID: 50181
Summary: const clang::ArrayType
*clang::Type::castAsArrayTypeUnsafe() const: Assertion
`isa(CanonicalType)' failed.
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: rmansfi...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk,
wchild...@lock3software.com
$ cat ice.ii
typedef struct {
char *a;
} b;
struct c {
b c;
} d{(char[]){""}};
$ bin/clang ice.ii
clang-13:
/home/ryan_mansfield/llvm/llvm-project/clang/include/clang/AST/Type.h:7232:
const clang::ArrayType *clang::Type::castAsArrayTypeUnsafe() const: Assertion
`isa(CanonicalType)' failed.
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:
/home/ryan_mansfield/llvm/llvm-project/build/bin/clang-13 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations
-disable-free -main-file-name ice.ii -mrelocation-model static
-mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb
-fcoverage-compilation-dir=/home/ryan_mansfield/llvm/llvm-project/build
-resource-dir /home/ryan_mansfield/llvm/llvm-project/build/lib/clang/13.0.0
-fdeprecated-macro
-fdebug-compilation-dir=/home/ryan_mansfield/llvm/llvm-project/build
-ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions
-fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o
/tmp/ice-04ea8a.o -x c++-cpp-output ice.ii
1. parser at end of file
2. ice.ii:4:8: LLVM IR generation of declaration 'c'
3. ice.ii:6:3: Generating code for declaration 'd'
#0 0x01e40bd3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
#1 0x01e3ecb0 llvm::sys::RunSignalHandlers()
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Signals.cpp:77:18
#2 0x01e4109f SignalHandler(int)
/home/ryan_mansfield/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1
#3 0x779ae980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#4 0x76505fb7 raise
/build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x76507921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0
#6 0x764f748a __assert_fail_base
/build/glibc-S7xCS9/glibc-2.27/assert/assert.c:89:0
#7 0x764f7502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#8 0x0235205a llvm::cast_retty::ret_type llvm::cast(clang::Type
const*)
/home/ryan_mansfield/llvm/llvm-project/llvm/include/llvm/Support/Casting.h:269:3
#9 0x0235205a clang::Type::castAsArrayTypeUnsafe() const
/home/ryan_mansfield/llvm/llvm-project/clang/include/clang/AST/Type.h:7234:10
#10 0x043090ed clang::APValue::isArray() const
/home/ryan_mansfield/llvm/llvm-project/clang/include/clang/AST/APValue.h:400:38
#11 0x043090ed clang::APValue::getArrayInitializedElts() const
/home/ryan_mansfield/llvm/llvm-project/clang/include/clang/AST/APValue.h:522:5
#12 0x043090ed CheckEvaluationResult(CheckEvaluationResultKind,
(anonymous namespace)::EvalInfo&, clang::SourceLocation, clang::QualType,
clang::APValue const&, clang::Expr::ConstantExprKind, clang::SourceLocation,
llvm::SmallPtrSet&)
/home/ryan_mansfield/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2355:36
#13 0x04309156 CheckEvaluationResult(CheckEvaluationResultKind,
(anonymous namespace)::EvalInfo&, clang::SourceLocation, clang::QualType,
clang::APValue const&, clang::Expr::ConstantExprKind, clang::SourceLocation,
llvm::SmallPtrSet&)
/home/ryan_mansfield/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2356:12
#14 0x042daedd CheckConstantExpression((anonymous
namespace)::EvalInfo&, clang::SourceLocation, clang::QualType, clang::APValue
const&, clang::Expr::ConstantExprKind)
/home/ryan_mansfield/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2423:10
#15 0x042dc34b EvaluateAsRValue((anonymous namespace)::EvalInfo&,
clang::Expr const*, clang::APValue&)
/home/ryan_mansfield/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14627:60
#16 0x042d89e6 EvaluateAsRValue(clang::Expr const*,
clang::Expr::EvalResult&, clang::ASTContext const&, (anonymous
namespace)::EvalInfo&)
/home/ryan_mansfield/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14673:10
#17 0x042d89e6 clang::Expr::EvaluateAsRValue(clang::Expr::EvalResult&,
clang::ASTContext const&, bool) const
/home/ryan
[llvm-bugs] [Bug 49989] Off-by-one error in overwrite path of MutationDispatcher::ApplyDictionaryEntry
https://bugs.llvm.org/show_bug.cgi?id=49989 Fabian Meumertzheim changed: What|Removed |Added Resolution|--- |FIXED 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 50182] New: Segmentation fault / null pointer exception
https://bugs.llvm.org/show_bug.cgi?id=50182 Bug ID: 50182 Summary: Segmentation fault / null pointer exception Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llvm-symbolizer Assignee: unassignedb...@nondot.org Reporter: marcel.swider...@stud.tu-darmstadt.de CC: llvm-bugs@lists.llvm.org Created attachment 24816 --> https://bugs.llvm.org/attachment.cgi?id=24816&action=edit A minimal example program that causes the crash + Makefile that generates the three cases I described When compiling one of the CFI-showcase programs (attached) with CFI instrumentation and recovery a nullpointer exception in llvm-symbolizer occurs. The program is not clean by design - this is the point of a CFI showcase - but it runs fine without any instrumentation enabled. It also runs fine with instrumentation enabled (-fsanitize=cfi-icall) - the violation is reported and the program aborts gracefully. However, with instrumentation (-fsanitize=cfi-icall) AND recovery (-fsanitize-recover=all) enabled, the program does not resume execution after the CFI violation has been reported. A nullpointer exception causes a crash. All other CFI showcase programs resume correctly, only this one case causes a crash. Expected behavior: $ ./cfi_skip_entrypoint cfi_skip_entrypoint.c:35:15: runtime error: control flow integrity check for type 'int (int)' failed during indirect function call CFI ensures control flow only transfers to potentially valid destinations In not_entry_point: (0) If you can read this, execution has resumed! >>> The program should report the violation and continue execution Actual behavior: $ ./cfi_skip_entrypoint cfi_skip_entrypoint.c:35:15: runtime error: control flow integrity check for type 'int (int)' failed during indirect function call (/mnt/clang-cfi-showcase/cfi_skip_entrypoint+0x423c40): note: __libc_csu_init defined here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior cfi_skip_entrypoint.c:35:15 in UndefinedBehaviorSanitizer:DEADLYSIGNAL ==23263==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x (pc 0x00423c71 bp 0x00086ce8 sp 0x7ffe258018d8 T23263) ==23263==The signal is caused by a READ memory access. ==23263==Hint: address points to the zero page. #0 0x423c71 in __libc_csu_init (/mnt/clang-cfi-showcase/cfi_skip_entrypoint+0x423c71) #1 0x423c2f (/mnt/clang-cfi-showcase/cfi_skip_entrypoint+0x423c2f) UndefinedBehaviorSanitizer can not provide additional info. SUMMARY: UndefinedBehaviorSanitizer: SEGV (/mnt/clang-cfi-showcase/cfi_skip_entrypoint+0x423c71) in __libc_csu_init ==23263==ABORTING >>> The program reports the violation but cannot resume because of a >>> nullpointer exception This is what I got after debugging it in gdb: Thread 2.1 "llvm-symbolizer" received signal SIGSEGV, Segmentation fault. Run till exit from #0 __libc_start_main (main=0x423ad0 , argc=1, argv=0x7fffe758, init=0x423c30 <__libc_csu_init>, fini=, rtld_fini=, stack_end=0x7fffe748) at ../csu/libc-start.c:268 cfi_skip_entrypoint.c:35:15: runtime error: control flow integrity check for type 'int (int)' failed during indirect function call >>> CFI violation is reported correctly <<< [Attaching after Thread 0x778bdb80 (LWP 35794) fork to child process 35828] [New inferior 2 (process 35828)] [Detaching after fork from parent process 35794] [Inferior 1 (process 35794) detached] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". process 35828 is executing new program: /usr/lib/llvm-11/bin/llvm-symbolizer >>> Execution resumes, llvm-symbolizer is called <<< [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Thread 2.1 "llvm-symbolizer" received signal SIGSEGV, Segmentation fault. -- 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 50179] clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:596: clang::ento::loc::MemRegionVal::MemRegionVal(const clang::ento::MemRegion *): Assertion `r' failed.
https://bugs.llvm.org/show_bug.cgi?id=50179 Denys Petrov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Denys Petrov --- The fix has been loaded. https://reviews.llvm.org/D101635 -- 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 50183] New: Preferred canonicalization - select-of-idx vs select-of-gep ?
https://bugs.llvm.org/show_bug.cgi?id=50183
Bug ID: 50183
Summary: Preferred canonicalization - select-of-idx vs
select-of-gep ?
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
If we're selecting between the base address and base+idx, which is the
preferred canonicalization?
define <4 x i32> @select0(<4 x i32>* %a0, i64 %a1, i1 %a2) {
%gep = getelementptr inbounds <4 x i32>, <4 x i32>* %a0, i64 %a1
%sel = select i1 %a2, <4 x i32>* %a0, <4 x i32>* %gep
%res = load <4 x i32>, <4 x i32>* %sel
ret <4 x i32> %res
}
select0:
shlq$4, %rsi
addq%rdi, %rsi
testb $1, %dl
cmovneq %rdi, %rsi
vmovaps (%rsi), %xmm0
retq
define <4 x i32> @select1(<4 x i32>* %a0, i64 %a1, i1 %a2) {
%sel = select i1 %a2, i64 %a1, i64 0
%gep = getelementptr inbounds <4 x i32>, <4 x i32>* %a0, i64 %sel
%res = load <4 x i32>, <4 x i32>* %gep
ret <4 x i32> %res
}
select1:
xorl%eax, %eax
testb $1, %dl
cmovneq %rsi, %rax
shlq$4, %rax
vmovaps (%rdi,%rax), %xmm0
retq
https://godbolt.org/z/Yxs3fjbWo
opt -O3 doesn't seem to have any effect.
X86 could have a slight preference for select1 (select-of-idx) as it moves more
of the address math into the fold, which is useful if the base address has
additional uses (the use case this was pulled from was clamping the
out-of-bounds indices to zero for several of these in an unrolled loop).
--
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 50174] [MCA][ARM] Assertion failed regarding CarryOver value in the DispatchStage
https://bugs.llvm.org/show_bug.cgi?id=50174
Min-Yih Hsu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Min-Yih Hsu ---
@Andrea thank you for your rapid fix :-)
Closing this bug now...
> I believe NOP's are aliases for a certain type of tHINT's in the arm backend.
Yes, actually the original sequence that triggered this bug was
```
pop {r3, r4, r5, r6, r7, pc}
hint#0
```
I thought it's more clear to write `nop` rather than `hint` and they both
triggered the same bug.
--
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 50184] New: [Feature request] Tab completion on user defined alias
https://bugs.llvm.org/show_bug.cgi?id=50184 Bug ID: 50184 Summary: [Feature request] Tab completion on user defined alias Product: lldb Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: tom.pou...@gmail.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Hi ! I was advised to file a bug report after I had posted my issue on StackOverflow : https://stackoverflow.com/questions/67231162/lldb-tab-completion-after-user-defined-aliases/67305975#67305975 I defined the following alias in lldb : command alias bfn breakpoint set -n %1 Sadly, this alias does not allow Tab completion as the regular command does. All the time gained in typing the command is lost typing whole identifiers that are sometimes quite complex. Nevertheless, buit-in aliases allow for completion so I assume there's a way to achieve the same behaviour for user defined aliases. Thanks for your time and the work you put in making great software. -- 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 50071] -Woverloaded-virtual and -Wdefaulted-function-deleted when building M68k backend with clang
https://bugs.llvm.org/show_bug.cgi?id=50071 Nick Desaulniers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Desaulniers --- https://reviews.llvm.org/rG93bc038126304cffc230fbc5561c78efa6fe4209 -- 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 33820 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: Values->first == PN1 && Values->second == PN2
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 33820 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: Values->first == PN1 && Values->second == PN2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33820#c1 ClusterFuzz testcase 6144028845408256 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202104290600:202104300622 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 50185] New: decouple Diagnostics from clang
https://bugs.llvm.org/show_bug.cgi?id=50185 Bug ID: 50185 Summary: decouple Diagnostics from clang Product: flang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedb...@nondot.org Reporter: ndesaulni...@google.com CC: david.tr...@arm.com, echri...@gmail.com, jper...@nvidia.com, kirankuma...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk, sscalp...@nvidia.com I was surprised to find out that flang depends on clang, seemingly only for the diagnostic engine support. I can understand how the dependency came to be, but I'd imagine that such dependencies between flang and clang can accidentally grow over time. Does it make sense to move the diagnostics engine out of clang? Should flang have it's own diagnostics engine? -- 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 50186] New: Linker creates invalid executables that crash dyld when linking Intel IPP
https://bugs.llvm.org/show_bug.cgi?id=50186 Bug ID: 50186 Summary: Linker creates invalid executables that crash dyld when linking Intel IPP Product: lld Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: caleb.zulaw...@gmail.com CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com I'm trying lld 12 for macOS and can link and run trivial executables. However when I move on to another (unfortunately proprietary) codebase the generated executables cause the following error from dyld: dyld: REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 0 which is not a writable segment (__TEXT) in dist/lib/libxyz.dylib.1 It's worth noting that libxyz is static linked against Intel's IPP which I'm guessing has a slightly different object format, since I think it's compiled with ICC. I am using clang with the -fuse-ld=lld.darwinnew option. -- 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 50187] New: LLVM prefer lzcnt too strongly - extra computation required
https://bugs.llvm.org/show_bug.cgi?id=50187
Bug ID: 50187
Summary: LLVM prefer lzcnt too strongly - extra computation
required
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
long long clz64(long long num) {
return 63LL - __builtin_clzll(num | 1);
}
int clz32(unsigned num) {
return 31 - __builtin_clz(num | 1);
}
int clz32_a(unsigned num) {
return 31 - __builtin_clz(num);
}
LLVM -march=haswell -O3
clz64(long long): # @clz64(long long)
or rdi, 1
lzcnt rax, rdi
xor rax, 63
ret
clz32(unsigned int): # @clz32(unsigned int)
or edi, 1
lzcnt eax, edi
xor eax, 31
ret
clz32_a(unsigned int):# @clz32_a(unsigned int)
lzcnt eax, edi
xor eax, 31
ret
GCC -march=haswell -O3
clz64(long long):
or rdi, 1
bsr rax, rdi
ret
clz32(unsigned int):
or edi, 1
bsr eax, edi
ret
clz32_a(unsigned int):
bsr eax, edi
ret
https://gcc.godbolt.org/z/r4bYfocKG
--
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 50188] New: segfault when compiling with unusal parameters
https://bugs.llvm.org/show_bug.cgi?id=50188 Bug ID: 50188 Summary: segfault when compiling with unusal parameters Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: tobias.k...@gmx.de CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 24817 --> https://bugs.llvm.org/attachment.cgi?id=24817&action=edit files referenced by crash log I've been trying various parameters to compile "raw" x86_64 assembly and tried unusual combinations when I encountered this error. The console asked me to report it so I'm doing that. ~/test$ clang -nostdinc -nostdlib -ffreestanding -fuse-ld=lld --target=x86_64-pc-windows-eabi -v test.cpp clang version 10.0.0-4ubuntu1 Target: x86_64-pc-windows-eabi Thread model: posix InstalledDir: /usr/bin "/usr/lib/llvm-10/bin/clang" -cc1 -triple x86_64-pc-windows-eabi -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -ffreestanding -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -nostdsysteminc -nobuiltininc -resource-dir /usr/lib/llvm-10/lib/clang/10.0.0 -fdeprecated-macro -fdebug-compilation-dir /home/zarat/test -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o /tmp/test-a8fb80.o -x c++ test.cpp clang -cc1 version 10.0.0 based upon LLVM 10.0.0 default target x86_64-pc-linux-gnu #include "..." search starts here: End of search list. Stack dump: 0. Program arguments: /usr/lib/llvm-10/bin/clang -cc1 -triple x86_64-pc-windows-eabi -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -ffreestanding -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -nostdsysteminc -nobuiltininc -resource-dir /usr/lib/llvm-10/lib/clang/10.0.0 -fdeprecated-macro -fdebug-compilation-dir /home/zarat/test -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o /tmp/test-a8fb80.o -x c++ test.cpp 1. parser at end of file 2. Code generation #0 0x7f996c51e4ff llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x9814ff) #1 0x7f996c51c7b0 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x97f7b0) #2 0x7f996c51eac5 (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x981ac5) #3 0x7f9972cee420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x15420) #4 0x7f996d4bb036 (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x191e036) #5 0x7f996d4b7dec (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x191adec) #6 0x7f996d46c3af llvm::MCAssembler::layout(llvm::MCAsmLayout&) (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x18cf3af) #7 0x7f996d46c798 llvm::MCAssembler::Finish() (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x18cf798) #8 0x7f996cb5a4b7 llvm::AsmPrinter::doFinalization(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xfbd4b7) #9 0x7f996c6240b1 llvm::FPPassManager::doFinalization(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xa870b1) #10 0x7f996c624572 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xa87572) #11 0x7f9971619433 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 >) (/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x13e8433) #12 0x7f9971898e1c (/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x1667e1c) #13 0x7f9970a86c13 clang::ParseAST(clang::Sema&, bool, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x855c13) #14 0x7f9971efce58 clang::FrontendAction::Execute() (/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x1ccbe58) #15 0x7f9971eb58a1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x1c848a1) #16 0x7f9971f60daf clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x1d2fdaf) #17 0x0041229d cc1_main(llvm::ArrayRef, char const*, void*) (/usr/lib/llvm-10/bin/clang+0x41229d) #18 0x004105b1 (/usr/lib/llvm-10/bin/clang+0x41
[llvm-bugs] [Bug 50189] New: Missed optimization to auto-vectorize __builtin_bitreverse
https://bugs.llvm.org/show_bug.cgi?id=50189
Bug ID: 50189
Summary: Missed optimization to auto-vectorize
__builtin_bitreverse
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: scov...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This code:
#include
#define DEFINE_BITREVERSE_LOOP(N) \
void bitreverse##N##_loop(int##N##_t* values, int n) { \
for (int i = 0; i < n; i++) { \
values[i] = __builtin_bitreverse##N(values[i]); \
} \
} \
DEFINE_BITREVERSE_LOOP(8);
DEFINE_BITREVERSE_LOOP(16);
DEFINE_BITREVERSE_LOOP(32);
DEFINE_BITREVERSE_LOOP(64);
When compiled with -O3 -march=armv8.2-a+fp16+rcpc+dotprod+crypto+simd+crc
Both clang-9 and clang-11 produce all kinds of code (sometimes even
auto-vectorized, for bytes), instead of just passing vector registers to the
rbit instruction.
This seems a bit ironic, given that __builtin_bitreverse was originally
invented to support arm rbit.
--
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 50190] New: Possible Issue with Whole Program Devirtualization
https://bugs.llvm.org/show_bug.cgi?id=50190
Bug ID: 50190
Summary: Possible Issue with Whole Program Devirtualization
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: stepl...@quicinc.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
class A {
public:
virtual int foo() const = 0;
};
class B : public A {
public:
virtual int foo() const { return 2; }
};
class C : public A {
public:
virtual int foo() const { return 3; }
};
A *get_A(int num) {
if (num > 1) {
printf("returning new B\n");
return new B;
}
printf("returning new C\n");
return new C;
}
__attribute__((noinline))
void call_foo(int argc) {
C *c = (C *)get_A(argc);
printf("%d\n", c->foo());
}
int main(int argc, char *argv[]) {
call_foo(argc);
}
trunk clang with -O3 -flto -whole-program-vtables -fvisibility=hidden outputs
./a.out 1
returning new B
3
gcc 10.2 with -O3 -flto -fwhole-program -fvisibility=hidden outputs
./a.out 1
returning new B
2
It looks like the c->foo is being devirtualized to a direct C::foo() call.
--
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 50190] Possible Issue with Whole Program Devirtualization
https://bugs.llvm.org/show_bug.cgi?id=50190 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Smith --- Yes, this is UB. We'll even do this devirtualization in the frontend if C or C::foo is final. -- 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 33856 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Preprocessor::PeekAhead
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-05-01 Type: Bug New issue 33856 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Preprocessor::PeekAhead https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33856 Detailed Report: https://oss-fuzz.com/testcase?key=6443933795221504 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc71347e48 Crash State: clang::Preprocessor::PeekAhead clang::Parser::isCXX11AttributeSpecifier clang::Parser::ParseDeclarationSpecifiers Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202104280624:202104290600 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6443933795221504 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] Issue 33858 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-05-01 Type: Bug New issue 33858 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33858 Detailed Report: https://oss-fuzz.com/testcase?key=6709977558417408 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe8d7a4fe0 Crash State: clang::DeclContext::lookup clang::DeclContext::using_directives UnqualUsingDirectiveSet::addUsingDirectives Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202104280624:202104290600 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6709977558417408 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] Issue 33864 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupName
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-05-01 Type: Bug New issue 33864 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33864 Detailed Report: https://oss-fuzz.com/testcase?key=4524446472863744 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffca7632fd8 Crash State: clang::Sema::LookupName clang::Sema::LookupTemplateName clang::Sema::isTemplateName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011180625:202011190626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4524446472863744 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
