GEP instruction change

Hi All,
Since few days I observe weird change.
Consider the following C code

char array = “0123456789”;
extern int test(char arr, int size);

int main(void) {
return test(array-1, sizeof(array)-1);
}

using clang frontend i get this:

%call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0, i32 -1), i32 10) ; [#uses=1]

and using LLVM-GCC this:
%1 = call i32 @test(i8* getelementptr ([11 x i8]* @array, i32 1561806289, i32 4), i32 10) nounwind ; [#uses=1]

Should the second getelementptr look like this? Is it correct or a bug?
Since that change there’s a problem in MSIL backend - it simply triggers pointer overflow assertion.

Artur

Hi All,
Since few days I observe weird change.
Consider the following C code

char array = "0123456789";
extern int test(char arr, int size);

int main(void) {
return test(array-1, sizeof(array)-1);
}

using clang frontend i get this:

%call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0,
i32 -1), i32 10) ; <i32> [#uses=1]

and using LLVM-GCC this:
%1 = call i32 @test(i8* getelementptr ([11 x i8]* @array, i32 1561806289,
i32 4), i32 10) nounwind ; <i32> [#uses=1]

Should the second getelementptr look like this? Is it correct or a bug?

Indexing out of an array is undefined behavior per C99, but that
particular result does look strange...

Since that change there's a problem in MSIL backend - it simply triggers
pointer overflow assertion.

Sorry, I don't know anything about the MSIL backend.

-Eli

Hi All,
Since few days I observe weird change.
Consider the following C code

char array = “0123456789”;
extern int test(char arr, int size);

int main(void) {
return test(array-1, sizeof(array)-1);
}

using clang frontend i get this:

%call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0,
i32 -1), i32 10) ; [#uses=1]

and using LLVM-GCC this:
%1 = call i32 @test(i8* getelementptr ([11 x i8]* @array, i32 1561806289,
i32 4), i32 10) nounwind ; [#uses=1]

Should the second getelementptr look like this? Is it correct or a bug?

Indexing out of an array is undefined behavior per C99, but that
particular result does look strange…

So it isn’t a bug?
It’s weird that it simply started to happen few days ago and only with llvm-gcc.

Artur Pietrek wrote:

     > Hi All,
     > Since few days I observe weird change.
     > Consider the following C code
     >
     > char array = "0123456789";
     > extern int test(char arr, int size);
     >
     > int main(void) {
     > return test(array-1, sizeof(array)-1);
     > }
     >
     > using clang frontend i get this:
     >
     > %call = call i32 @test(i8* getelementptr inbounds ([11 x i8]*
    @array, i32 0,
     > i32 -1), i32 10) ; <i32> [#uses=1]
     >
     > and using LLVM-GCC this:
     > %1 = call i32 @test(i8* getelementptr ([11 x i8]* @array, i32
    1561806289,
     > i32 4), i32 10) nounwind ; <i32> [#uses=1]
     >
     > Should the second getelementptr look like this? Is it correct or
    a bug?

    Indexing out of an array is undefined behavior per C99, but that
    particular result does look strange...

So it isn't a bug?
It's weird that it simply started to happen few days ago and only with llvm-gcc.

Maybe the GEP overflow folding stuff Dan committed recently doesn't
handle negative indices properly.

Ciao,

Duncan.

Hi All,
Since few days I observe weird change.
Consider the following C code

char array = "0123456789";
extern int test(char arr, int size);

int main(void) {
  return test(array-1, sizeof(array)-1);
}

As Eli mentioned, this invokes undefined behavior.

using clang frontend i get this:

%call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0, i32 -1), i32 10) ; <i32> [#uses=1]

I get the same code for clang and llvm-gcc. Did you rebuild clang?

and using LLVM-GCC this:
%1 = call i32 @test(i8* getelementptr ([11 x i8]* @array, i32 1561806289, i32 4), i32 10) nounwind ; <i32> [#uses=1]

Should the second getelementptr look like this? Is it correct or a bug?

It's a bug, though a subtle one. The first index is truncated
incorrectly. It should be 390451572, and the second index 3, since
it looks like you're using a 32-bit target and 39045157*11+3 is -1
when interpreted as a 32-bit signed integer. This is now fixed.

Since that change there's a problem in MSIL backend - it simply triggers pointer overflow assertion.

This sounds like a bug in the MSIL backend regardless.

Dan