bug in llvm-gcc implementation of long long

Project Infrastructure LLVM Dev List Archives
1

Compiling the following C code

2

I get this:

long %f4() {
entry:
         ret long 2147483648
}

What does the preprocessed output of that function look like?

-Chris

3

What does the preprocessed output of that function look like?

long long f4(void) {
  return (long long)2147483647 + 1;
}

Using 2147483648LL directly causes the same problem.

-Chris

Best Regards,
Rafael

4

What target triple?

-Chris

5

What target triple?

i486-linux-gnu

-Chris

Rafael

6

Okay, that is very very strange. This sounds like a failure in the GCC part of the compiler somehow, as constant+constant is folded before we get to it. Can you try to track this down a bit to see what is going wrong?

-Chris

7

Okay, that is very very strange. This sounds like a failure in the GCC
part of the compiler somehow, as constant+constant is folded before we
get to it. Can you try to track this down a bit to see what is going
wrong?

Sure. I will have a look tomorrow morning. Maybe it is a bug in the
particular GCC revision that is used. I will try to compile it without
LLVM and check.

-Chris

Best Regards,
Rafael

8

Rafael Espíndola wrote:

> return (long long)INT_MAX + 1;

does it work in ordinary gcc? I recall I had a problem with this in an earlier version of gcc, maybe they still haven't fixed it.

m.

9

does it work in ordinary gcc? I recall I had a problem with this in an earlier version of gcc, maybe they still haven't
fixed it.

Works in vanilla 4.1

Rafael

10

does it work in ordinary gcc? I recall I had a problem with this in an earlier version of gcc, maybe they still haven't
fixed it.

I have just compiled revision 102 without --enable-llvm and the
resulting code correctly sets edx to 0.

Time to try gdb.

Rafael

11

Time to try gdb.

The problem was a cast of a 32 bits signed number to a 64 unsigned
number. A patch is attached. I am currently trying a bootstrap to make
sure this doesn't brake anything.

Rafael

gcc-long-long.patch (1.06 KB)

12

Interesting. I wonder why that wasn't getting triggered for me. Perhaps the signedness of HOST_WIDE_INT changes or something? In any case, I've applied your patch, including the one to match the arm target triple.

Thanks!

-Chris