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
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: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,
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: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
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
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
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 */
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
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
> 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
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 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
13 matches
Mail list logo
