[llvm-dev] A strange problem about type i64 for LLVM

[Qiuping Yi via llvm-dev]

Thanks for your help and advice. I have found the problem, which is
resulted from my own code.


Best regards,

Qiuping Yi
Parasol Laboratory
Department of Computer Science and Engineering
Texas A&M University
College Station
TX 77843

On Wed, Jul 12, 2017 at 11:45 AM, mats petersson <mats at planetcatfish.com>
wrote:

> I think this requires "complete code" (ideally the smallest possible that
> still reproduces the problem), not snippets. It is quite likely that the
> problem is somewhere other than in the precise lines quoted.
>
> Using 64-bit values in x86 is far from rare, but it's of course possible
> that:
> 1. you have found a rare bug because your code is doing something unusual.
> 2. there is a bug somewhere in your own code, that you haven't spotted.
>
> The bits of code you have posted don't look wrong, but they also aren't
> showing enough code to determine "yes that should work" or "no, that is
> wrong because ..."
>
> --
> Mats
>
> On 12 July 2017 at 17:24, Qiuping Yi via llvm-dev <llvm-dev at lists.llvm.org
> > wrote:
>
>> Hi Tim Northover,
>>
>> I just use Mac OS X, Intel Core i5. 'retValue' is initialized, computed,
>> and then returned from 'myFunction', so I think this problem is not
>> introduced by uninitialized value. In addition, '306205760' is not
>> a meaningless value, but the result of truncating '140583176769504' to
>> 32 bits.
>>
>> Actually, I instrumented some call instructions for value store and load,
>> which can be simplified as follow:
>>
>> 1. Storing values with function 'myStore':
>>        call void myStore(i64 %1);
>>
>> 2. Loading values with function 'myLoad':
>>        %0 = call i64 myLoad();
>>
>> The problem is that the call on 'myStore' can correctly pass 'i64 %1' to
>> the function body of 'myStore'. However, when I use 'myLoad' to return the
>> stored value to '%0', the 64bits value is truncated to a 32bits value. For
>> example, '140583176769504' is returned in 'myLoad', but actually '306205760'
>> is assigned to %0.
>>
>>
>>
>>
>>
>> Best regards,
>>
>> Qiuping Yi
>> Parasol Laboratory
>> Department of Computer Science and Engineering
>> Texas A&M University
>> College Station
>> TX 77843
>>
>> On Wed, Jul 12, 2017 at 10:16 AM, Tim Northover <t.p.northover at gmail.com>
>> wrote:
>>
>>> On 12 July 2017 at 11:10, Qiuping Yi via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>> > int64_t myFunction() {
>>> >      int64_t retValue;
>>> >      ...
>>> >      std::cout << "retValue: " << retValue << "\n";
>>> >      return retValue;
>>> > }
>>>
>>> If retValue isn't initialized then this program has undefined
>>> behaviour as C++ so all bets are off (LLVM might be propagating an
>>> "undef" and simply not returning a meaningful value).
>>>
>>> Otherwise we need more detail. I'd expect this to work on all targets
>>> (int64_t would in almost every case map to i64, and this straight
>>> return should be fine, particularly if it comes from C++). So are you
>>> using a custom target and does it have any quirks that might be
>>> relevant? The key functions to look at would be LowerCall and
>>> LowerReturn in XYZISelLowering.cpp.
>>>
>>> Cheers.
>>>
>>> Tim.
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/eb1eb079/attachment.html>