root REPL problem with unsigned num assigned to a not declared item

[Asxcvbn]

• [ x] Checked for duplicates

Describe the bug

in root interpreter, we may:

root [0] unsigned long a=5;

and then

root [1] b=a;

and it returns a number

(unsigned long) 140055251333128

which is totally unexpected.

Expected behavior

we expect to yield:

(unsigned long)5

To Reproduce

code generally described above.
you just need to:
start root interpretor

$root

and run the lines in it

root [0] unsigned long a=5;
(unsigned long) 5
root [1] b=a;

note other unsigned integer types also bug.

root [2] unsigned int c
(unsigned int) 0
root [3] d=c
Error in <TRint::HandleTermInput()>: std::runtime_error caught: >>> Interpreter compilation error:
expected relocatable expression

root [4] unsigned char e=5
(unsigned char) '0x05'
root [5] f=e
Error in <TRint::HandleTermInput()>: std::runtime_error caught: >>> Interpreter compilation error:
expected relocatable expression

Setup

splash screen

   ------------------------------------------------------------------
  | Welcome to ROOT 6.22/02                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Aug 17 2020, 12:46:52                 |
  | From tags/v6-22-02@v6-22-02                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |
   ------------------------------------------------------------------

ROOT 6.22/02 on CentOS7 x86_64, at CVMFS

/cvmfs/sft.cern.ch/lcg/app/releases/ROOT/6.22.02/x86_64-centos7-gcc48-opt

and
ROOT 6.20/06 on CentOS7/gcc x86_64, installed by system admin in my server
ROOT 6.22/02 on windows/MSVC x86_64, binary download

did not tested on current HEAD.

strangely, older version, like ROOT5.34/09 or ROOT 5.34/36 on linuxx8664gcc, has no such problem.

ROOT 5.34/36 (v5-34-36@v5-34-36, Apr 05 2016, 10:25:45 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
root [0] unsigned long a=5
root [1] b=a
Warning: Automatic variable b is allocated (tmpfile):1:
(unsigned long)5

Additional context

[jalopezg-git]

Hello @Asxcvbn,

I have reproduced this bug and already have a fix for it. However, because we are currently upgrading to LLVM 9, I will wait until then to apply the fix -this will happen at some point in January-.

Cheers,
J.

[jalopezg-git]

Hi @Asxcvbn,

The patch has been sent for inclusion in the LLVM 9 upgrade branch. This issue will be closed once this branch is merged into master.

Cheers.

[jalopezg-git]

Recently, the upgrade_llvm90 branch was merged into master. This branch already includes the proposed fix.