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

[Qiuping Yi via llvm-dev]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/3a92a864/attachment-0001.html>