llvm dev - Aug 2009 - [LLVMdev] 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) ; <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?
Since that change there's a problem in MSIL backend - it simply triggers
pointer overflow assertion.

Artur
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090821/acfb1819/attachment.html>

On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com>
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...
> 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

On Fri, Aug 21, 2009 at 12:33 PM, Eli Friedman <eli.friedman at
gmail.com>wrote:
> On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com>
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.


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

On Aug 21, 2009, at 2:02 AM, 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);
> }
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