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