On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss wrote:
> -llvm-dev + lldb-dev for the lldv test failures.
>
> On Jan 3, 2019, at 7:33 AM, Joel E. Denny wrote:
>
> All,
>
> Thanks for the replies. Kuba: For LLDB, when were things expected to have
> improved? It's possible things improved for me a
Consider this example program:
#include
#include
#include
#include
#include
#include
int
main(void)
{
// Target process for the debugger.
pid_t pid = fork();
if (pid < 0)
err(1, "fork");
if (pid == 0)
while (true)
pause();
lldb::SBDebugger::Initialize();
{
au
> On Jan 4, 2019, at 7:30 AM, Joel E. Denny wrote:
>
> On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss wrote:
> -llvm-dev + lldb-dev for the lldv test failures.
>
>> On Jan 3, 2019, at 7:33 AM, Joel E. Denny wrote:
>>
>> All,
>>
>> Thanks for the replies. Kuba: For LLDB, when were things ex
Hi Everyone,
In September I sent out an RFC [1] about adding reproducers to LLDB. Over
the
past few months, I landed the reproducer framework, support for the GDB
remote
protocol and a bunch of preparatory changes. There's still an open code
review
[2] for dealing with files, but that one is curre
While adding support for 512-bit integers in `Scalar`, I figured I
could add some coverage.
TEST(ScalarTest, Signedness) {
auto s1 = Scalar(APInt(32, 12, false /* isSigned */));
auto s2 = Scalar(APInt(32, 12, true /* isSigned */ ));
ASSERT_EQ(s1.GetType(), Scalar::e_uint); // fails
ASSERT_EQ(s
On Fri, Jan 4, 2019 at 1:57 PM Davide Italiano wrote:
>
> While adding support for 512-bit integers in `Scalar`, I figured I
> could add some coverage.
>
> TEST(ScalarTest, Signedness) {
> auto s1 = Scalar(APInt(32, 12, false /* isSigned */));
> auto s2 = Scalar(APInt(32, 12, true /* isSigned */
If I understand the situation correctly I think we should do both. I'd
start by doing (2) to improve the current behavior and add a constructor
for APSInt. We can then audit the call sites and migrate to APSInt where
it's obvious that the type is signed. That should match the semantics of
both clas
I don't think #2 is a correct change. Just because the sign bit is set
doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
unsigned? It's a trick question, because there's not enough information!
If it was written "int x = 0x1000" then it's signed (and negative). If
it was wr
On Fri, Jan 4, 2019 at 3:13 PM Zachary Turner wrote:
> I don't think #2 is a correct change. Just because the sign bit is set
> doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
> unsigned? It's a trick question, because there's not enough information!
> If it was written "int
Option 3? Add APSInt as a new member?
Current:
Scalar::Type m_type;
llvm::APInt m_integer;
llvm::APFloat m_float;
bool m_ieee_quad = false;
Option #3:
Scalar::Type m_type;
llvm::APInt m_uint;
llvm::APSInt m_sint;
llvm::APFloat m_float;
bool m_ieee_quad = false;
I don't know
On Fri, Jan 4, 2019 at 3:23 PM Jonas Devlieghere
wrote:
> On Fri, Jan 4, 2019 at 3:13 PM Zachary Turner wrote:
>
>> I don't think #2 is a correct change. Just because the sign bit is set
>> doesn't mean it's signed. Is the 4-byte value 0x1000 signed or
>> unsigned? It's a trick question,
It seems like we have 3 uses of this constructor in LLDB.
IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant.
IRForTarget.cpp: Constructs a Scalar for an llvm::Constant.
ClangASTContext.cpp: bitcasts an APFloat to an APInt.
The first two we should just treat constants in LLVM IR as sig
On Fri, Jan 4, 2019 at 3:54 PM Zachary Turner wrote:
>
> It seems like we have 3 uses of this constructor in LLDB.
>
> IRInterpreter.cpp: Constructs a Scalar for an llvm::Constant.
> IRForTarget.cpp: Constructs a Scalar for an llvm::Constant.
> ClangASTContext.cpp: bitcasts an APFloat to an APInt
13 matches
Mail list logo
