|
Mario Charest
10/21/2010 2:12 PM
post71838
|
I have a feeling the following is a compiler bug (6.5.0):
#include <string.h>
struct Second {
char dummy[1000000];
};
struct First {
struct Second second;
};
struct Second test;
void foo( struct First *val ) {
struct Second *sec = &val->second;
memcpy( &test, sec, sizeof ( struct Second ) );
}
When compile with no optimisation it looks like:
pushl %ebp
movl %esp, %ebp
subl $40, %esp
movl 8(%ebp), %eax
movl %eax, -12(%ebp)
movl $1000000, 8(%esp)
movl -12(%ebp), %eax
movl %eax, 4(%esp)
movl $test, (%esp)
call memcpy
leave
ret
When compile with -O
pushl %ebp
movl %esp, %ebp
pushl %ebx
>> subl $1000020, %esp
leal -1000008(%ebp), %ebx
movl $1000000, 8(%esp)
movl 8(%ebp), %eax
movl %eax, 4(%esp)
movl %ebx, (%esp)
call memcpy
movl $1000000, 8(%esp)
movl %ebx, 4(%esp)
movl $test, (%esp)
call memcpy
addl $1000020, %esp
popl %ebx
popl %ebp
ret
This is BAD, 1M is allocated on the stack, and the data referenced by *sec is first copied onto the stack before being
copy by the memcpy in the C code. Of course the program crashed because the stack isn't big enough. Even if the stack
would be big enough that's some major overhead ...
I tried to figure out the -f option that trigger this behavior ( by getting the list via --help=optimizers ) but no luck
.
If I changed the file extention from c to cpp to get it to compile with g++ the "bug" is no there.
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
|
|
Aleksandar Ristovski(deleted)
10/21/2010 2:21 PM
post71842
|
Out of curiousity, would
-fconserve-stack
change things?
On Thu, 2010-10-21 at 14:12 -0400, Mario Charest wrote:
> I have a feeling the following is a compiler bug (6.5.0):
>
> #include <string.h>
>
> struct Second {
> char dummy[1000000];
> };
>
> struct First {
> struct Second second;
> };
>
> struct Second test;
>
> void foo( struct First *val ) {
> struct Second *sec = &val->second;
> memcpy( &test, sec, sizeof ( struct Second ) );
> }
>
> When compile with no optimisation it looks like:
>
> pushl %ebp
> movl %esp, %ebp
> subl $40, %esp
> movl 8(%ebp), %eax
> movl %eax, -12(%ebp)
> movl $1000000, 8(%esp)
> movl -12(%ebp), %eax
> movl %eax, 4(%esp)
> movl $test, (%esp)
> call memcpy
> leave
> ret
>
> When compile with -O
>
> pushl %ebp
> movl %esp, %ebp
> pushl %ebx
> >> subl $1000020, %esp
> leal -1000008(%ebp), %ebx
> movl $1000000, 8(%esp)
> movl 8(%ebp), %eax
> movl %eax, 4(%esp)
> movl %ebx, (%esp)
> call memcpy
> movl $1000000, 8(%esp)
> movl %ebx, 4(%esp)
> movl $test, (%esp)
> call memcpy
> addl $1000020, %esp
> popl %ebx
> popl %ebp
> ret
>
> This is BAD, 1M is allocated on the stack, and the data referenced by
> *sec is first copied onto the stack before being copy by the memcpy in
> the C code. Of course the program crashed because the stack isn't big
> enough. Even if the stack would be big enough that's some major
> overhead ...
>
> I tried to figure out the -f option that trigger this behavior ( by
> getting the list via --help=optimizers ) but no luck.
>
> If I changed the file extention from c to cpp to get it to compile
> with g++ the "bug" is no there.
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post71838
>
>
>
|
|
|
|
|
|
Mario Charest
10/21/2010 4:11 PM
post71872
|
> -----Message d'origine-----
> De : Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> Envoyé : 21 octobre 2010 14:28
> À : general-toolchain
> Objet : Re: Compiler Bug ?
>
> Out of curiousity, would
>
> -fconserve-stack
>
> change things?
No change, the generated assembly code is identical.
>
>
>
> On Thu, 2010-10-21 at 14:12 -0400, Mario Charest wrote:
> > I have a feeling the following is a compiler bug (6.5.0):
> >
> > #include <string.h>
> >
> > struct Second {
> > char dummy[1000000];
> > };
> >
> > struct First {
> > struct Second second;
> > };
> >
> > struct Second test;
> >
> > void foo( struct First *val ) {
> > struct Second *sec = &val->second;
> > memcpy( &test, sec, sizeof ( struct Second ) ); }
> >
> > When compile with no optimisation it looks like:
> >
> > pushl %ebp
> > movl %esp, %ebp
> > subl $40, %esp
> > movl 8(%ebp), %eax
> > movl %eax, -12(%ebp)
> > movl $1000000, 8(%esp)
> > movl -12(%ebp), %eax
> > movl %eax, 4(%esp)
> > movl $test, (%esp)
> > call memcpy
> > leave
> > ret
> >
> > When compile with -O
> >
> > pushl %ebp
> > movl %esp, %ebp
> > pushl %ebx
> > >> subl $1000020, %esp
> > leal -1000008(%ebp), %ebx
> > movl $1000000, 8(%esp)
> > movl 8(%ebp), %eax
> > movl %eax, 4(%esp)
> > movl %ebx, (%esp)
> > call memcpy
> > movl $1000000, 8(%esp)
> > movl %ebx, 4(%esp)
> > movl $test, (%esp)
> > call memcpy
> > addl $1000020, %esp
> > popl %ebx
> > popl %ebp
> > ret
> >
> > This is BAD, 1M is allocated on the stack, and the data referenced by
> > *sec is first copied onto the stack before being copy by the memcpy in
> > the C code. Of course the program crashed because the stack isn't big
> > enough. Even if the stack would be big enough that's some major
> > overhead ...
> >
> > I tried to figure out the -f option that trigger this behavior ( by
> > getting the list via --help=optimizers ) but no luck.
> >
> > If I changed the file extention from c to cpp to get it to compile
> > with g++ the "bug" is no there.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > General
> > http://community.qnx.com/sf/go/post71838
> >
> >
> >
>
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post71842
>
|
|
|
|
|
|
Mario Charest
11/12/2010 3:39 PM
post74526
|
No comments, anyone? This sound to me like a very nasty bug.
> I have a feeling the following is a compiler bug (6.5.0):
>
> #include <string.h>
>
> struct Second {
> char dummy[1000000];
> };
>
> struct First {
> struct Second second;
> };
>
> struct Second test;
>
> void foo( struct First *val ) {
> struct Second *sec = &val->second;
> memcpy( &test, sec, sizeof ( struct Second ) );
> }
>
> When compile with no optimisation it looks like:
>
> pushl %ebp
> movl %esp, %ebp
> subl $40, %esp
> movl 8(%ebp), %eax
> movl %eax, -12(%ebp)
> movl $1000000, 8(%esp)
> movl -12(%ebp), %eax
> movl %eax, 4(%esp)
> movl $test, (%esp)
> call memcpy
> leave
> ret
>
> When compile with -O
>
> pushl %ebp
> movl %esp, %ebp
> pushl %ebx
> >> subl $1000020, %esp
> leal -1000008(%ebp), %ebx
> movl $1000000, 8(%esp)
> movl 8(%ebp), %eax
> movl %eax, 4(%esp)
> movl %ebx, (%esp)
> call memcpy
> movl $1000000, 8(%esp)
> movl %ebx, 4(%esp)
> movl $test, (%esp)
> call memcpy
> addl $1000020, %esp
> popl %ebx
> popl %ebp
> ret
>
> This is BAD, 1M is allocated on the stack, and the data referenced by *sec is
> first copied onto the stack before being copy by the memcpy in the C code. Of
> course the program crashed because the stack isn't big enough. Even if the
> stack would be big enough that's some major overhead ...
>
> I tried to figure out the -f option that trigger this behavior ( by getting
> the list via --help=optimizers ) but no luck.
>
> If I changed the file extention from c to cpp to get it to compile with g++
> the "bug" is no there.
>
>
>
>
>
|
|
|
|
|
|
Oleh Derevenko(deleted)
11/13/2010 12:37 PM
post74556
|
> No comments, anyone? This sound to me like a very nasty bug.
Why can't you allocate that structure dynamically with malloc? Having large objects in data segment is bad as is a bad
style to have global static variables in general.
|
|
|
|
|
|
Mario Charest
11/20/2010 12:12 PM
post75431
|
> > No comments, anyone? This sound to me like a very nasty bug.
>
> Why can't you allocate that structure dynamically with malloc? Having large
> objects in data segment is bad as is a bad style to have global static
> variables in general.
You totally missed the point. This is a test case to show a compiler bug. I should not have to modifidy my code to go
around a compiler bug however bad the code is. Whether an object is statly or dynamically allocated they all go in the
data segment. That being said the issue is NOT with how the variable test is instanciated, in fact try it with a malloc
and you will that nothing changes. The bug is with this line:
struct Second *sec = &val->second;
Although this should only copy 4 bytes; the address of val->second, it actually copies the content of val->second onto
the STACK!!!! Not only does it increase the likely hood of stack overwflow but it hurt performances.
|
|
|
|
|
|
