[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #28 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c28 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-9a196b80-3ab5-4aa4-ba86-e68cc689a82f.txt -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40193] New: Wrong overload being selected
https://bugs.llvm.org/show_bug.cgi?id=40193
Bug ID: 40193
Summary: Wrong overload being selected
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: dominique.pe...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This program gives a different output with clang and gcc:
$ cat foo.cpp
#include
#include
#include
#include
void foo(const char* s)
{
std::printf("in foo(const char*)\n");
}
void foo(const boost::variant& v)
{
std::printf("in foo(const boost::variant&)\n");
}
int main()
{
foo(0);
foo(std::uint64_t(0));
foo(std::uint32_t(0));
foo(NULL);
foo(nullptr);
}
With clang (I tried clang-7.0, clang-6.0, clang-5.0.2, clang-4.0, clang-3.9.1)
it prints:
$ clang++-7 -std=c++11 foo.cpp
$ ./a,out
in foo(const char*)
in foo(const boost::variant&)
in foo(const boost::variant&)
in foo(const char*)
in foo(const char*)
With gcc (I tried gcc-8.1.0, gcc-7.4.0, gcc-5.5) it prints:
$ g++-8 -std=c++11 foo.cpp
$ ./a.out
in foo(const char*)
in foo(const char*)
in foo(const char*)
in foo(const char*)
in foo(const char*)
Notice the different overdload functions are being invoked
when using clang or gcc.
I'm not 100% sure, but it looks like a clang bug after
reading http://www.dcs.bbk.ac.uk/~roger/cpp/week20.htm
Furthermore, using https://godbolt.org/ I see that other
compilers msvc v19 and Intel icc 19.0.1 behave like gcc,
which tends to confirm that it's a problem with clang.
Or is it caused by undefined behavior?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40194] New: BDCE clears poison flags too aggressively
https://bugs.llvm.org/show_bug.cgi?id=40194 Bug ID: 40194 Summary: BDCE clears poison flags too aggressively Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org BDCE currently clears poison generating flags on all instructions that might have been affected by a dead use. However, we don't actually have to do this for all instructions. In particular shl, lshr and ashr already take their nuw/nsw/exact flags into account when computing demanded bits. Only add, sub and mul compute demanded bits without respecting nuw/nsw. As such, it should be sufficient to clear poison flags on add, sub and mul only. This also matches what SimplifyDemandedBits in InstCombine does. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40195] New: Compile error related to constexpr variable template in a template class
https://bugs.llvm.org/show_bug.cgi?id=40195
Bug ID: 40195
Summary: Compile error related to constexpr variable template
in a template class
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++'17
Assignee: unassignedclangb...@nondot.org
Reporter: ambr...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following C++17 program does not compile:
template
struct A {
template
inline static constexpr int X = 1;
inline static constexpr int Y = X;
};
constexpr int Y = A::Y;
clang++ -std=c++17 main.cpp
main.cpp:7:19: error: constexpr variable 'Y' must be initialized by a constant
expression
constexpr int Y = A::Y;
^~
1 error generated.
This error is produced with any Clang version starting with 5.0.0 (where
sufficient C++17 support appeared). It compiles with GCC (7.1 and newer).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12157 in oss-fuzz: llvm/clang-fuzzer: Timeout in clang-fuzzer
Comment #2 on issue 12157 by ClusterFuzz-External: llvm/clang-fuzzer: Timeout in clang-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12157#c2 ClusterFuzz has detected this issue as fixed in range 201812310412:201901010410. Detailed report: https://oss-fuzz.com/testcase?key=5720605752557568 Project: llvm Fuzzer: libFuzzer_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: clang-fuzzer Sanitizer: address (ASAN) Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812310412:201901010410 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5720605752557568 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12157 in oss-fuzz: llvm/clang-fuzzer: Timeout in clang-fuzzer
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 12157 by ClusterFuzz-External: llvm/clang-fuzzer: Timeout in clang-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12157#c3 ClusterFuzz testcase 5720605752557568 is verified as fixed, so closing issue as verified. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10883 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Null-dereference READ in llvm::AArch64RegisterBankInfo::getInstrMapping
Updates: Labels: Deadline-Approaching Comment #4 on issue 10883 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-gisel: Null-dereference READ in llvm::AArch64RegisterBankInfo::getInstrMapping https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10883#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40196] New: printf bug when arguments from a member of union
https://bugs.llvm.org/show_bug.cgi?id=40196
Bug ID: 40196
Summary: printf bug when arguments from a member of union
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: met...@x-legend.com.tw
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Hi
We found a bug in printf.
It may have included below
1. 64bit union
2. a bit number in union
3. out of register count (x64-ABI limit)
#include
union U {
unsigned long long Value;
struct {
unsigned long long Data:2;
};
};
int main ()
{
int a = 0;
U b = { 0 };
printf ("%d, %llu\n", a, b.Data);
printf ("%d, %d, %llu\n", a, a, b.Data);
printf ("%d, %d, %d, %llu\n", a, a, a, b.Data);
printf ("%d, %d, %d, %d, %llu\n", a, a, a, a, b.Data);
printf ("%d, %d, %d, %d, %d, %llu\n", a, a, a, a, a, b.Data);
printf ("%d, %d, %d, %d, %d, %d, %llu\n", a, a, a, a, a, a, b.Data);
printf ("%d, %d, %d, %d, %d, %d, %d, %llu\n", a, a, a, a, a, a, a, b.Data);
printf ("%d, %d, %d, %d, %d, %d, %d, %d, %llu\n", a, a, a, a, a, a, a, a,
b.Data);
printf ("%d, %d, %d, %d, %d, %d, %d, %d, %d, %llu\n", a, a, a, a, a, a, a,
a, a, b.Data);
return 0;
}
metora@pro-debian:$ clang-6.0 1.cc
metora@pro-debian:$ ./a.out
0, 0
0, 0, 0
0, 0, 0, 0
0, 0, 0, 0, 0
0, 0, 0, 0, 0, 140724603453440
0, 0, 0, 0, 0, 0, 140724603453440
0, 0, 0, 0, 0, 0, 0, 0
0, 0, 0, 0, 0, 0, 0, 0, 0
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
How to fix or prevent it?
Thank you
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39771] Funnel shift simplification based on demanded bits fails on multiple uses
https://bugs.llvm.org/show_bug.cgi?id=39771 Nikita Popov changed: What|Removed |Added Fixed By Commit(s)||https://reviews.llvm.org/rL ||350188 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Nikita Popov --- Fixed by https://reviews.llvm.org/rL350188. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40197] New: c11: Rejects valid program dereferencing pointer with incomplete reference type.
https://bugs.llvm.org/show_bug.cgi?id=40197
Bug ID: 40197
Summary: c11: Rejects valid program dereferencing pointer with
incomplete reference type.
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: anders.granlun...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Test case (prog.c):
struct S *p;
void f(void);
int main()
{
f();
*p;
}
struct S { int x; };
void f()
{
static struct S s = { 0 };
p = &s;
}
Compilation command line:
clang prog.c -Wall -Wextra -std=c11 -pedantic-errors
Observed behaviour:
The following error message was outputed:
prog.c:9:5: error: incomplete type 'struct S' where a complete type is
required
*p;
^
prog.c:1:8: note: forward declaration of 'struct S'
struct S *p;
^
Expected behaviour:
No error message outputed.
I can't find anything in the standard that makes the this program invalid.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40193] Wrong overload being selected
https://bugs.llvm.org/show_bug.cgi?id=40193
Richard Smith changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Smith ---
Thanks for the report. The situation here is a little complicated:
In ISO C++14 onwards, 0 cast to some other type is not a null pointer constant
any more, so cannot be implicitly converted to const char*.
This change was made in core issue 903
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#903), which was
moved in DR ("defect report") status, which means the intent is that it applies
retroactively to at least the prior standard. As a result, Clang applies this
change in C++11 onwards.
The extent to which other vendors track defect reports and apply them
retroactively is up to them, but this is intended behaviour in Clang.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12359 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-01-02 Type: Bug New issue 12359 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12359 Detailed report: https://oss-fuzz.com/testcase?key=5718310669254656 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff98647fd8 Crash State: ConvertDeclSpecToType GetDeclSpecTypeForDeclarator clang::Sema::GetTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812200235:201812210355 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5718310669254656 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40198] New: regression: assertion triggered in DwarfUnit
https://bugs.llvm.org/show_bug.cgi?id=40198 Bug ID: 40198 Summary: regression: assertion triggered in DwarfUnit Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: and...@ziglang.org CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com Created attachment 21282 --> https://bugs.llvm.org/attachment.cgi?id=21282&action=edit test.ll This is a regression in trunk from LLVM 7.0.0. The Zig Standard Library tests in --release-safe mode trigger an assertion in LLVM trunk, but not in LLVM 7.0.0. Trunk commit: commit 99cd11ca6529d6b0f3ef38bc4933c78158334771 (HEAD -> master, origin/master, origin/HEAD) Author: Robert Widmann Date: Tue Jan 1 19:03:37 2019 + [LLVM-C] bool -> LLVMBool Backtrace, with some debug info printed: #31 0x01d9cc8b in ZigLLVMTargetMachineEmitToFile (targ_machine_ref=0xaa049e0, module_ref=0xaa01f70, filename=0x4616c3c0 "zig-cache/test.o", output_type=ZigLLVM_EmitBinary, error_message=0x7fffb2a8, is_debug=false, is_small=false, time_report=false) at /store/dev/zig/src/zig_llvm.cpp:193 193 MPM.run(*module); (gdb) #30 0x05ee7bed in llvm::legacy::PassManager::run (this=0x7fffafc0, M=...) at /store/dev/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1888 1888 return PM->run(M); (gdb) #29 0x05ee79be in llvm::legacy::PassManagerImpl::run (this=0x3b4bf250, M=...) at /store/dev/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1857 1857Changed |= getContainedManager(Index)->runOnModule(M); (gdb) #28 0x05ee7226 in (anonymous namespace)::MPPassManager::runOnModule (this=0xefd97a0, M=...) at /store/dev/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1744 1744 LocalChanged |= MP->runOnModule(M); (gdb) #27 0x05ee6e7a in llvm::FPPassManager::runOnModule (this=0x4662bbe0, M=...) at /store/dev/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1679 1679Changed |= runOnFunction(F); (gdb) #26 0x05ee6c56 in llvm::FPPassManager::runOnFunction (this=0x4662bbe0, F=...) at /store/dev/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1644 1644 LocalChanged |= FP->runOnFunction(F); (gdb) #25 0x04b5dca2 in llvm::MachineFunctionPass::runOnFunction (this=0xbaab500, F=...) at /store/dev/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:74 74bool RV = runOnMachineFunction(MF); (gdb) #24 0x043557d3 in llvm::X86AsmPrinter::runOnMachineFunction (this=0xbaab500, MF=...) at /store/dev/llvm-project/llvm/lib/Target/X86/X86AsmPrinter.cpp:78 78EmitFunctionBody(); (gdb) #23 0x04929fa3 in llvm::AsmPrinter::EmitFunctionBody (this=0xbaab500) at /store/dev/llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1230 1230HI.Handler->endFunction(MF); (gdb) #22 0x04946e97 in llvm::DebugHandlerBase::endFunction (this=0x4c9d2860, MF=0x4efc9380) at /store/dev/llvm-project/llvm/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp:319 319 endFunctionImpl(MF); (gdb) p MF->dump() # Machine code for function init_vdso_clock_gettime: NoPHIs, TracksLiveness, NoVRegs bb.0.Then: DBG_VALUE $edi, $noreg, !"clk", !DIExpression(), debug-location !3639; index.zig:968:35 line no:968 DBG_VALUE $rsi, $noreg, !"ts", !DIExpression(), debug-location !3640; index.zig:968:45 line no:968 DBG_VALUE 0, $noreg, !"addr", !DIExpression(), debug-location !3641; index.zig:969:5 line no:969 DBG_VALUE 0, $noreg, !"f", !DIExpression(), debug-location !3642; index.zig:970:5 line no:970 renamable $rax = LEA64r $rip, 1, $noreg, @init_vdso_clock_gettime, $noreg, debug-location !3643; index.zig:971:9 renamable $ecx = XOR32rr undef $ecx(tied-def 0), undef $ecx, implicit-def dead $eflags, implicit-def $rcx LCMPXCHG64 $rip, 1, $noreg, @vdso_clock_gettime, $noreg, killed renamable $rcx, implicit-def dead $rax, implicit-def dead $eflags, implicit $rax, debug-location !3643 :: (volatile load store monotonic monotonic 8 on `i64* bitcast (i64 (i32, %timespec.41*)** @vdso_clock_gettime to i64*)`); index.zig:971:9 $rax = MOV64ri32 -38, debug-location !3645; index.zig:972:28 RETQ $rax, debug-location !3645; index.zig:972:28 # End machine code for function init_vdso_clock_gettime. $2 = void (gdb) up #21 0x04958f84 in llvm::DwarfDebug::endFunctionImpl (this=0x4c9d2860, MF=0x4efc9380) at /store/dev/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1615 1615 DIE &ScopeDIE = TheCU.constructSubprogramScopeDIE(SP, FnScope); (gdb) #20 0x04a1c3b5 in llvm::DwarfCompileUnit::constructSubprogramScopeDIE (this=0xaa07fd0, Sub=0x4ac18250, Scope=0x4e889b10) at /store/dev/llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfCom
[llvm-bugs] [Bug 40199] New: `file not found` when target.expr-prefix file `#include`'s another file
https://bugs.llvm.org/show_bug.cgi?id=40199
Bug ID: 40199
Summary: `file not found` when target.expr-prefix file
`#include`'s another file
Product: lldb
Version: unspecified
Hardware: All
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: thelastmamm...@gmail.com
CC: llvm-bugs@lists.llvm.org
~/.lldbinit:
```
settings set target.expr-prefix /tmp/lldb_prefix.h
```
/tmp/lldb_prefix.h:
```
#include "/tmp2/compiler_nim.c" // works
#include // error: 'limits.h' file not found
#include "compiler_nim.c" // ditto
```
```
(lldb) p printf("")
error: 'limits.h' file not found
```
* How do I specify an `-I` include path for `target.expr-prefix` `expr` or `p`
commands?
I looked at the sources for that error and found
$git_clone_D/llvm/tools/llvm-rc/ResourceFileWriter.cpp ; it showed:
`FindInEnvPath("INCLUDE", File, Params.NoInclude))`
however setting `export INCLUDE="/tmp2"` before calling lldb didn't work
I also tried
`settings set target.source-map . /tmp2`, didn't work
I also tried: `target.input-path`, didn't work
* for standard library headers (eg `#include `), how can I avoid
`file not found` without specifying explicitly search path (which can be
tricky to find, local disk search reveal lots of options and I just want the
"standard" as used by clang etc to be used)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40200] New: color prompt causes wrong indentation of cmds (with `settings set prompt "\033[31m(lldb)\033[0m "`)
https://bugs.llvm.org/show_bug.cgi?id=40200 Bug ID: 40200 Summary: color prompt causes wrong indentation of cmds (with `settings set prompt "\033[31m(lldb)\033[0m "`) Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: thelastmamm...@gmail.com CC: llvm-bugs@lists.llvm.org ~/.lldbinit: ``` settings set prompt "\033[31m(lldb)\033[0m " ``` this "almost" works, it it shows a colored prompt (red), however, it causes wrong indentation between prompt and typed commands. ``` (lldb) platform shell pwd /Users/timothee/git_clone/llvm/tools/lldb (lldb) ``` I suspect that the bug is likely caused by line editor naively counting the number of chars in given prompt, instead of number of printable chars. Could we allow (as workaround) user to specify actual width (and user is responsible for specifying the correct amount of printable characters) Where would that be in code? -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
