Re: reducing stack size by breaking SPARC ABI for OS-less environments
> As I have no window overflow trap handler the space reserved on the > stack for saving in and local registers is just wasted memory. Is there > any way I can reclaim this space by forcing the compiler to not honour > the standard SPARC ABI? No, there isn't, unless you want to hack the compiler. Note that this would break exception handling. -- Eric Botcazou
Re: gcc-4.3.2 native build error
Chandra Prakash Garg writes: > checking for > i686-pc-linux-gnu-gcc... > /home/abhijitd/gcc/gcc-4.3.2/host-i686-pc-linux-gnu/gcc/xgcc > -B/home/abhijitd/gcc/gcc-4.3.2/host-i686-pc-linux-gnu/gcc/ > -B/home/abhijitd/gcc/gcc-4.3.2/i686-pc-linux-gnu/bin/ > -B/home/abhijitd/gcc/gcc-4.3.2/i686-pc-linux-gnu/lib/ -isystem > /home/abhijitd/gcc/gcc-4.3.2/i686-pc-linux-gnu/include -isystem > /home/abhijitd/gcc/gcc-4.3.2/i686-pc-linux-gnu/sys-include > checking for suffix of object files... configure: error: cannot > compute suffix of object files: cannot compile > See `config.log' for more details. gcc@gcc.gnu.org is the wrong mailing list. Please take this question to gcc-h...@gcc.gnu.org. Please include the details in config.log. Actually, this is your problem: > ./configure As described in the installation documentation, do not run ./configure. Instead, run SRCDIR/configure in an empty directory. Please take any followups to gcc-h...@gcc.gnu.org. Thanks. Ian
A bug?
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int main(){
printf("%s\n",s().world);
}
Assigning s() to a variable and then using the variable avoids the
segfault.
gcc --version returns (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
Regards,
Michel
Re: A bug?
> Hi,
>
> The following program segfaults when compiled with gcc
> but runs fine when compiled with g++ or icc (the intel C compiler)
>
> #include
> struct Hello {
> char world[20];
> };
> struct Hello s(){
> struct Hello r;
> r.world[0]='H';
> r.world[1]='\0';
> return r;
> }
>
> int main(){
> printf("%s\n",s().world);
> }
>
> Assigning s() to a variable and then using the variable avoids the
> segfault.
compiles and works fine with GCC 4.3.2 on Solaris 8/9/10 sun4m/sun4u/i386
$ /opt/csw/gcc4/bin/gcc -v -o foo.o -c foo.c
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
--enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
--with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib --enable-bootstrap
Thread model: posix
gcc version 4.3.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v foo.c
-quiet -dumpbase foo.c -mcpu=v7 -auxbase-strip foo.o -version -o
/var/tmp//ccAHrz2q.s
ignoring nonexistent directory
"/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/csw/include
/opt/csw/gcc4/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.2 (sparc-sun-solaris2.8)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version
2.3.1.
warning: GMP header version 4.2.2 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
Compiler executable checksum: 1ac791ab3c2b7cc8775dc74d45095fef
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
/usr/ccs/bin/as -V -Qy -s -xarch=v8 -o foo.o /var/tmp//ccAHrz2q.s
/usr/ccs/bin/as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch
114802-02
COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/:/usr/ccs/bin/
LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/usr/ccs/lib/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
$ /opt/csw/gcc4/bin/gcc -v -o foo.s -S -c foo.c
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
--enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
--with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib --enable-bootstrap
Thread model: posix
gcc version 4.3.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v foo.c
-quiet -dumpbase foo.c -mcpu=v7 -auxbase-strip foo.s -version -o foo.s
ignoring nonexistent directory
"/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/csw/include
/opt/csw/gcc4/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.2 (sparc-sun-solaris2.8)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version
2.3.1.
warning: GMP header version 4.2.2 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
Compiler executable checksum: 1ac791ab3c2b7cc8775dc74d45095fef
COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/:/usr/ccs/bin/
LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/usr/ccs/lib/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
$ cat foo.s
.file "foo.c"
.section".text"
.align 4
.global s
.type s, #function
.proc 010
s:
save%sp, -136, %sp
ld [%fp+64], %l0
mov 72, %g
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
> Hi,
>
> The following program segfaults when compiled with gcc
> but runs fine when compiled with g++ or icc (the intel C compiler)
>
> #include
> struct Hello {
> char world[20];
> };
> struct Hello s(){
> struct Hello r;
> r.world[0]='H';
> r.world[1]='\0';
> return r;
> }
>
> int main(){
> printf("%s\n",s().world);
> }
>
> Assigning s() to a variable and then using the variable avoids the segfault.
Had you compiled with -Wall would you have noticed:
e.c:13: warning: format ‘%s’ expects type ‘char *’, but
argument 2 has type ‘char[20]’
And when there is a type mismatch, a crash is pretty likely.
Not that I can say why gcc does not convert it to char* but g++ does.
Now what happens? The following augmented snippet shows it:
---<8---
#include
#include
#include
struct Hello {
char world[20];
};
struct Hello s(void)
{
struct Hello r;
strcpy(r.world, "Hello");
return r;
}
static void dump(const char *fmt, ...)
{
va_list argp;
va_start(argp, fmt);
char *p = va_arg(argp, char *);
printf("%p\n", p);
va_end(argp);
}
int main(void)
{
dump("", s().world);
return 0;
}
--->8---
I get 0x6c6c6548, which is obviously part of the string Hello. So
passing a char[20] into a varargs function seems not to convert it to
char* when done through a non-visibile temporary (the result of s()
is hidden on the stack of main).
Fwd: A bug?
2008/12/16 Dennis Clarke :
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> struct Hello r;
>> r.world[0]='H';
>> r.world[1]='\0';
>> return r;
>> }
>>
>> int main(){
>> printf("%s\n",s().world);
>> }
>>
>> Assigning s() to a variable and then using the variable avoids the
>> segfault.
>
> compiles and works fine with GCC 4.3.2 on Solaris 8/9/10 sun4m/sun4u/i386
>
> $ /opt/csw/gcc4/bin/gcc -v -o foo.o -c foo.c
> Using built-in specs.
> Target: sparc-sun-solaris2.8
> Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
> --with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
> --enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
> --with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
> --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
> --enable-java-awt=xlib --with-system-zlib --enable-bootstrap
> Thread model: posix
> gcc version 4.3.2 (GCC)
> COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
> /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v foo.c
> -quiet -dumpbase foo.c -mcpu=v7 -auxbase-strip foo.o -version -o
> /var/tmp//ccAHrz2q.s
> ignoring nonexistent directory
> "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../../sparc-sun-solaris2.8/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /opt/csw/include
> /opt/csw/gcc4/include
> /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include
> /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include-fixed
> /usr/include
> End of search list.
> GNU C (GCC) version 4.3.2 (sparc-sun-solaris2.8)
>compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version
> 2.3.1.
> warning: GMP header version 4.2.2 differs from library version 4.2.4.
> GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
> Compiler executable checksum: 1ac791ab3c2b7cc8775dc74d45095fef
> COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
> /usr/ccs/bin/as -V -Qy -s -xarch=v8 -o foo.o /var/tmp//ccAHrz2q.s
> /usr/ccs/bin/as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch
> 114802-02
> COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/:/usr/ccs/bin/
> LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/usr/ccs/lib/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
>
> $ /opt/csw/gcc4/bin/gcc -v -o foo.s -S -c foo.c
> Using built-in specs.
> Target: sparc-sun-solaris2.8
> Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
> --with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
> --enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
> --with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
> --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
> --enable-java-awt=xlib --with-system-zlib --enable-bootstrap
> Thread model: posix
> gcc version 4.3.2 (GCC)
> COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
> /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v foo.c
> -quiet -dumpbase foo.c -mcpu=v7 -auxbase-strip foo.s -version -o foo.s
> ignoring nonexistent directory
> "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../../sparc-sun-solaris2.8/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /opt/csw/include
> /opt/csw/gcc4/include
> /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include
> /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include-fixed
> /usr/include
> End of search list.
> GNU C (GCC) version 4.3.2 (sparc-sun-solaris2.8)
>compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version
> 2.3.1.
> warning: GMP header version 4.2.2 differs from library version 4.2.4.
> GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
> Compiler executable checksum: 1ac791ab3c2b7cc8775dc74d45095fef
> COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/:/usr/ccs/bin/
> LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/usr/ccs/lib/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
>
> $ cat foo.s
>.file "foo.c"
Re: A bug?
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
(Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prints garbage (probably
uninitialized data).
g++ still works fine and does not give any warning, even when compiling
with -Wall.
Michel
Dennis Clarke wrote:
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int main(){
printf("%s\n",s().world);
}
Assigning s() to a variable and then using the variable avoids the
segfault.
compiles and works fine with GCC 4.3.2 on Solaris 8/9/10 sun4m/sun4u/i386
$ /opt/csw/gcc4/bin/gcc -v -o foo.o -c foo.c
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
--enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
--with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib --enable-bootstrap
Thread model: posix
gcc version 4.3.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v foo.c
-quiet -dumpbase foo.c -mcpu=v7 -auxbase-strip foo.o -version -o
/var/tmp//ccAHrz2q.s
ignoring nonexistent directory
"/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/csw/include
/opt/csw/gcc4/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.2 (sparc-sun-solaris2.8)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version
2.3.1.
warning: GMP header version 4.2.2 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
Compiler executable checksum: 1ac791ab3c2b7cc8775dc74d45095fef
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
/usr/ccs/bin/as -V -Qy -s -xarch=v8 -o foo.o /var/tmp//ccAHrz2q.s
/usr/ccs/bin/as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch
114802-02
COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/:/usr/ccs/bin/
LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/usr/ccs/lib/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.o' '-c' '-mcpu=v7'
$ /opt/csw/gcc4/bin/gcc -v -o foo.s -S -c foo.c
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-cpu=v7 --enable-threads=posix
--enable-nls --enable-shared --enable-languages=c,c++,fortran,objc
--with-gmp=/opt/csw --with-mpfr=/opt/csw --enable-multilib
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--enable-java-awt=xlib --with-system-zlib --enable-bootstrap
Thread model: posix
gcc version 4.3.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'foo.s' '-S' '-c' '-mcpu=v7'
/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/cc1 -quiet -v foo.c
-quiet -dumpbase foo.c -mcpu=v7 -auxbase-strip foo.s -version -o foo.s
ignoring nonexistent directory
"/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/csw/include
/opt/csw/gcc4/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.2 (sparc-sun-solaris2.8)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version
2.3.1.
warning: GMP header version 4.2.2 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
Compiler executable checksum: 1ac791ab3c2b7cc8775dc74d45095fef
COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.2/:/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/:/usr/ccs/bin/
LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/sparc-sun-sola
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
Ok thanks for the clear explanation! Not being able to threat char[] as a string is rather shocking to me though. Regards, Michel
Re: A bug?
Michel Van den Bergh wrote: That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10 (Intel core2 duo) I get stest.c: In function ‘main’: stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘char[20]’ The resulting binary does not segfault but prints garbage (probably uninitialized data). g++ still works fine and does not give any warning, even when compiling with -Wall. The C++ standard says in 5.2.2p7: "The lvalue-to-rvalue, array-to-pointer, and function-to-pointer standard conversions are performed on the argument expression." The C standard says no such thing; only integer promotions are performed. (See 6.5.2.2 of the C99 final draft.) Sebastian
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Sent from my iPhone
On Dec 16, 2008, at 8:45 AM, Jan Engelhardt wrote:
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int main(){
printf("%s\n",s().world);
}
Assigning s() to a variable and then using the variable avoids the
segfault.
Had you compiled with -Wall would you have noticed:
e.c:13: warning: format ‘%s’ expects type ‘char *’, but
argument 2 has type ‘char[20]’
And when there is a type mismatch, a crash is pretty likely.
Not that I can say why gcc does not convert it to char* but g++ does.
Now what happens? The following augmented snippet shows it:
---<8---
#include
#include
#include
struct Hello {
char world[20];
};
struct Hello s(void)
{
struct Hello r;
strcpy(r.world, "Hello");
return r;
}
static void dump(const char *fmt, ...)
{
va_list argp;
va_start(argp, fmt);
char *p = va_arg(argp, char *);
printf("%p\n", p);
va_end(argp);
}
int main(void)
{
dump("", s().world);
return 0;
}
--->8---
I get 0x6c6c6548, which is obviously part of the string Hello. So
passing a char[20] into a varargs function seems not to convert it to
char* when done through a non-visibile temporary (the result of s()
is hidden on the stack of main).
Re: A bug?
On Tuesday 2008-12-16 18:01, Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
>> (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 has
>> type ‘char[20]’
>>
> The C++ standard says in 5.2.2p7: "The lvalue-to-rvalue, array-to-pointer, and
> function-to-pointer standard conversions are performed on the argument
> expression."
>
> The C standard says no such thing; only integer promotions are performed. (See
> 6.5.2.2 of the C99 final draft.)
But what about
char t[20];
printf("%s\n", t);
typeof(t) is char[20], and if no promotion is performed,
how come it is converted to char* in C?
Re: A bug
The C standard says no such thing; only integer promotions are
performed. (See 6.5.2.2 of the C99 final draft.)
Ok one more question. Why does this not give a warning then (and runs fine)?
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int main(){
struct Hello a;
a=s();
printf("%s\n",a.world);
return 0;
}
In this case an implicit conversion of char[] to (char *) is happening
as well as far as I can see.
Regards,
Michel
Re: A bug?
Sebastian Redl wrote: > Michel Van den Bergh wrote: >> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu >> 8.10 (Intel core2 duo) >> I get >> >> stest.c: In function ‘main’: >> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 >> has type ‘char[20]’ >> >> The resulting binary does not segfault but prints garbage (probably >> uninitialized data). >> >> g++ still works fine and does not give any warning, even when >> compiling with -Wall. > The C++ standard says in 5.2.2p7: "The lvalue-to-rvalue, > array-to-pointer, and function-to-pointer standard conversions are > performed on the argument expression." > > The C standard says no such thing; It does, in 6.3.2.1. "Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue." Andrew.
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
Andrew Thomas Pinski wrote: > C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue > arrays in C++98. Also this code is still undefined C99 but will most > likely become valid C1x. Ah, it's an rvalue array. Good point. > Sent from my iPhone Advertising on gcc list. Dear me... ;-) Andrew.
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
>
> On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> struct Hello r;
>> r.world[0]='H';
>> r.world[1]='\0';
>> return r;
>> }
>>
>> int main(){
>> printf("%s\n",s().world);
>> }
>>
>> Assigning s() to a variable and then using the variable avoids the
>> segfault.
>
> Had you compiled with -Wall would you have noticed:
>
> e.c:13: warning: format â%sâ expects type âchar *â, but
> argument 2 has type âchar[20]â
>
> And when there is a type mismatch, a crash is pretty likely.
> Not that I can say why gcc does not convert it to char* but g++ does.
>
> Now what happens? The following augmented snippet shows it:
> ---<8---
> #include
> #include
> #include
> struct Hello {
>char world[20];
> };
> struct Hello s(void)
> {
> struct Hello r;
> strcpy(r.world, "Hello");
> return r;
> }
> static void dump(const char *fmt, ...)
> {
> va_list argp;
> va_start(argp, fmt);
> char *p = va_arg(argp, char *);
> printf("%p\n", p);
> va_end(argp);
> }
> int main(void)
> {
> dump("", s().world);
> return 0;
> }
> --->8---
>
> I get 0x6c6c6548, which is obviously part of the string Hello. So
> passing a char[20] into a varargs function seems not to convert it to
> char* when done through a non-visibile temporary (the result of s()
> is hidden on the stack of main).
On a baseline test machine ( Solaris 8 sun4m ) I get this with GCC 4.3.2 :
$ gcc -o foo2_gcc foo2.c
foo2.c: In function 'dump':
foo2.c:16: error: '__builtin_va_alist' undeclared (first use in this
function)
foo2.c:16: error: (Each undeclared identifier is reported only once
foo2.c:16: error: for each function it appears in.)
If I use very very old Sun Studio 8 I get this :
$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.5 Patch 112760-19 2007/08/02
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/SUNWspro/bin/cc -o foo2 foo2.c
$ mcs -p foo2
foo2:
@(#)stdarg.h1.4599/08/10 SMI
@(#)stdarg_iso.h1.1 99/08/09 SMI
@(#)va_list.h 1.1299/05/04 SMI
@(#)stdio.h 1.7899/12/08 SMI
@(#)stdio_iso.h 1.2 99/10/25 SMI
@(#)feature_tests.h 1.1899/07/26 SMI
@(#)isa_defs.h 1.2099/05/04 SMI
@(#)stdio_tag.h 1.3 98/04/20 SMI
@(#)stdio_impl.h1.8 99/06/10 SMI
@(#)string.h1.2499/08/10 SMI
@(#)string_iso.h1.2 99/11/09 SMI
acomp: Sun C 5.5 Patch 112760-19 2007/08/02
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.302
$ ./foo2
ec50
With Sun Studio 12 on Solaris 10 ( AMD64 this time ) I get
$ uname -a
SunOS isis 5.10 Generic_137138-09 i86pc i386 i86pc
$ cat /etc/release
Solaris 10 5/08 s10x_u5wos_10 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
$ /opt/studio/SOS12/SUNWspro/bin/cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
usage: cc [ options] files. Use 'cc -flags' for details
$ /opt/studio/SOS12/SUNWspro/bin/cc -o foo2 foo2.c
$ ./foo2
8047d70
so .. pretty wildly different results.
Dennis
--
Dennis Clarke
Re: gcc-4.3.2 generated "vmhraddshs" instruction when I compiled with -mcpu=8540
On Tue, Dec 16, 2008 at 12:28:10PM +0700, Ha Luong wrote:
> I used gcc-4.3.2 to compile the c source(*) and it generated
> "vmhraddshs" instruction when I compiled with -mcpu=8540.
> 000103A4: 11EB0321 vmhraddshs vr15,vr11,vr0,vr12
You are running into the problem that the Altivec and SPE opcode spaces
overlap, so the instructions that you see generated depend on what
disassembler you use. For example, compiling the assembler file test.s:
.text
.long 0x10074B20
.long 0x11eb0321
with:
powerpc-linux-gnu-gcc -c -o test.o test.s
and disassembling:
powerpc-linux-gnu-objdump -d test.o
gives you:
Disassembly of section .text:
<.text>:
0: 10 07 4b 20 vmhaddshs v0,v7,v9,v12
4: 11 eb 03 21 vmhraddshs v15,v11,v0,v12
but if you tell objdump to disassemble e500 instructions instead (use -M
e500x2 to include e500v2 instructions):
powerpc-linux-gnu-objdump -d -M e500 test.o
you see:
Disassembly of section .text:
<.text>:
0: 10 07 4b 20 evstddx r0,r7,r9
4: 11 eb 03 21 evstdd r15,0(r11)
The compiler is generating evstdd{,x} instructions, not vmhraddshs
instructions.
-Nathan
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
Andrew Haley wrote: Andrew Thomas Pinski wrote: C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue arrays in C++98. Also this code is still undefined C99 but will most likely become valid C1x. Ah, it's an rvalue array. Good point. Ok now I understand. I assume this behaviour is not triggered often as in C it is not so common to have an array which is an rvalue. Michel Sent from my iPhone Advertising on gcc list. Dear me... ;-) Andrew.
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
On Tue, Dec 16, 2008 at 9:43 AM, Michel Van den Bergh wrote: > Andrew Haley wrote: >> >> Andrew Thomas Pinski wrote: >> >>> >>> C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue >>> arrays in C++98. Also this code is still undefined C99 but will most >>> likely become valid C1x. > Ok now I understand. I assume this behaviour is not triggered often as in C > it is > not so common to have an array which is an rvalue. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37755 where it explains what is going on. Thanks, Andrew Pinski
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
On Tuesday 2008-12-16 18:43, Michel Van den Bergh wrote:
> Andrew Haley wrote:
>> Andrew Thomas Pinski wrote:
>>
>> > C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
>> > arrays in C++98. Also this code is still undefined C99 but will most
>> > likely become valid C1x.
>>
>> Ah, it's an rvalue array. Good point.
>>
> Ok now I understand. I assume this behaviour is not triggered often as in C it
> is
> not so common to have an array which is an rvalue.
Is not this a use of an rvalue array too?:
#include
int main(void)
{
printf("%p\n", (struct { char x[20]; }){{"Hello"}}.x);
}
This one actually works fine. So maybe it's really limited to
the case where a function returning a struct is involved.
Re: no conversion from char[] to char* on function calls under circumstances [was: A bug?]
On Tue, Dec 16, 2008 at 10:41 AM, Jan Engelhardt wrote:
> Is not this a use of an rvalue array too?:
>printf("%p\n", (struct { char x[20]; }){{"Hello"}}.x);
No, compound literals are always lvalues in C99.
Thanks,
Andrew Pinski
[avr]: potential runtime bug in insn andsi3?
Hi,
./gcc/config/avr/avr.md
defines andsi3 as follows:
(define_insn "andsi3"
[(set (match_operand:SI 0 "register_operand" "=r,d")
(and:SI (match_operand:SI 1 "register_operand" "%0,0")
(match_operand:SI 2 "nonmemory_operand" "r,i")))]
""
"*{
if (which_alternative==0)
...
else if (which_alternative==1)
{
if (GET_CODE (operands[2]) == CONST_INT)
{
HOST_WIDE_INT mask = INTVAL (operands[2]);
if ((mask & 0xff) != 0xff)
output_asm_insn (AS2 (andi,%A0,lo8(%2)), operands);
if ((mask & 0xff00) != 0xff00)
output_asm_insn (AS2 (andi,%B0,hi8(%2)), operands);
if ((mask & 0xffL) != 0xffL)
output_asm_insn (AS2 (andi,%C0,hlo8(%2)), operands);
if ((mask & 0xff00L) != 0xff00L)
output_asm_insn (AS2 (andi,%D0,hhi8(%2)), operands);
return \"\";
}
return ...
}
return \"bug\";
}"
[(set_attr "length" "4,4")
(set_attr "cc" "set_n,set_n")])
For alternative 1 "d,0,i" the effect on cc_status is described as set_n.
However, if the high byte of [2] is 0xff, then the PSW (i.e. SREG.N)
does not contain the MSB of the result.
I did not try to find a source that produces a bug basing on that,
but obviously the insn does not do what it states algebraically.
Besides that, andhi3 says cc=clobber in the similar case "d,0,i",
which is correct IMHO.
regards,
Georg-Johann
Re: Various memory sizes
On Mon, Dec 15, 2008 at 04:17:34PM -0500, gobaan_raveend...@amis.com wrote:
>
> Hello Everyone,
>
> I am working on an architecture with multiple types of memory and I am
> wondering about memory allocation. For the purpose of this explaination,
> we'll assume I am working with an embedded processor that has both 32 bit
> (named X) and 64 bit memory (named Y), 64 bit longs, and uses word
> addressing for both. Now given the following code
>
> int main ()
> {
> long array [5] = {1,2,3,4,5};
> return 0;
> }
>
> the compiler should determine increment based on the length of a long,
> however, if the data is in Y memory this is one, while if the data is in X
> memory the increment is two. The same problem holds for the offset of local
> variables and parameters that are longs etc.
>
> Given that I spent the last little while implementing a prototype that
> dealt with the named address space branch, I was able to quickly hack in
> some language hooks that allowed me to perform corrections to the increment
> for arrays based on their address space, and I may be able to extend this
> for other types as well. However, I think a correct & general
> implementation may change BITS_PER_UNIT and BITS_PER_WORD in order to
> generalize it for each address space (or at the very least introduce new
> macros that extend the behavior).
The problem as I've been finding in the named address branch, is at the end of
the day, you have to find all of the assumptions about Pmode, ptr_mode,
POINTER_SIZE, copy_to_addr_register, etc.
In terms of your code fragment, the named address spec also only allows named
address spaces for static memory. It assumes that stack based objects are all
in the generic address space. The compiler really believes there is only one
stack and that it can push/pop/reload at will.
One thing that I've thought about in terms of named address spaces is whether
you could use it to put in __little and __big to allow a user to encode that a
particular data item is little endian or big. However, you get back to the
stack issue again.
> I am just wondering about any other similar work, the feasibilty of either
> extension(my work is mainly a proof of concept), any input on how I should
> continue or comments on the mistakes of my assumptions.
In an ideal world, there should be a hook that allows a compiler to place each
variable in a particular named address space. However in doing so, you would
need to make sure that void */char * generally can point to any address space.
Otherwise it breaks a lot of C that requires void * be a universal pointer.
You might want to look at what other (non-GCC) compilers do for different
address spaces. I suspect that by and large, they just put the named address
stuff as special types of static, and use generic address spaces for auto
variables.
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com
Purpose of GCC Stack Padding?
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl%esp, %ebp
subl$X, %esp
leave
ret
Instead, the stack appears to be padded:
For a buffer size of 0the stack size is 0
For a buffer size of 1 to 7 the stack size is 16
For a buffer size of 8 to 12 the stack size is 24
For a buffer size of 13 to 28 the stack size is 40
For a buffer size of 29 to 44 the stack size is 56
For a buffer size of 45 to 60 the stack size is 72
For a buffer size of 61 to 76 the stack size is 88
For a buffer size of 77 to 92 the stack size is 104
For a buffer size of 93 to 100 the stack size is 120
When X >= 8 gcc adds a stack corruption check (__stack_chk_fail),
which accounts for an extra 4 bytes of stack space in these cases.
This does not explain the rest of the padding. Can anyone explain the
purpose of the rest of the padding?
Thanks,
Andrew.
PS There is a related thread on comp.lang.asm.x86. It contains the
script I used to compile the function and the full output:
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/2c8c5a2c6050179b/
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
--
Andrew Tomazos
Re: Purpose of GCC Stack Padding?
Andrew Tomazos wrote:
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl%esp, %ebp
subl$X, %esp
leave
ret
Instead, the stack appears to be padded:
For a buffer size of 0the stack size is 0
For a buffer size of 1 to 7 the stack size is 16
For a buffer size of 8 to 12 the stack size is 24
For a buffer size of 13 to 28 the stack size is 40
For a buffer size of 29 to 44 the stack size is 56
For a buffer size of 45 to 60 the stack size is 72
For a buffer size of 61 to 76 the stack size is 88
For a buffer size of 77 to 92 the stack size is 104
For a buffer size of 93 to 100 the stack size is 120
When X >= 8 gcc adds a stack corruption check (__stack_chk_fail),
which accounts for an extra 4 bytes of stack space in these cases.
This does not explain the rest of the padding. Can anyone explain the
purpose of the rest of the padding?
This looks like more of a gcc-help question, trying to move the thread
there. Unless you over-ride defaults with -mpreferred-stack boundary
(or -Os, which probably implies a change in stack boundary), or ask for
a change on the basis of making a leaf function, you are generating
alignment compatible with the use of SSE parallel instructions. The
stack, then, must be 16-byte aligned before entry and at exit, and also
a buffer of 16 bytes or more must be 16-byte aligned.
I believe there is a move afoot to standardize the treatment for the
most common x86 32-bit targets; that was done at the beginning for
64-bit. Don't know if you are using x86 to imply 32-bit, in accordance
with Windows terminology.
How can I determine a register is referred through MEM at split2 stage?
Hello Everyone, I am working on an optimization which happens at split2 stage. I need to determine whether the destination operand of the current RTL (which is a register operand) will be referred by other RTL through MEM within a basic block. I see there is a function named reg_mentioned_p (const_rtx reg, const_rtx in) in rtlanal.c to show whether REG appears somewhere within IN. It does help except that it can't tell me whether IN refers REG through MEM. Can anyone give me some suggestions? Thanks Xuepeng Guo
Re: gcc-4.3.2 generated "vmhraddshs" instruction when I compiled with -mcpu=8540
Hi Nathan,
Thanks for your guide. When I debugged the exe file or make it ran on
8548 board, the vmhaddshs makes the exe file hang out. Could I compile
the source for 8540 (e500v1 instructions) only?
Thanks for your help,
Ha Luong
On Tue, Dec 16, 2008 at 9:45 PM, Nathan Froyd wrote:
> On Tue, Dec 16, 2008 at 12:28:10PM +0700, Ha Luong wrote:
>> I used gcc-4.3.2 to compile the c source(*) and it generated
>> "vmhraddshs" instruction when I compiled with -mcpu=8540.
>> 000103A4: 11EB0321 vmhraddshs vr15,vr11,vr0,vr12
>
> You are running into the problem that the Altivec and SPE opcode spaces
> overlap, so the instructions that you see generated depend on what
> disassembler you use. For example, compiling the assembler file test.s:
>
>.text
>.long 0x10074B20
>.long 0x11eb0321
>
> with:
>
> powerpc-linux-gnu-gcc -c -o test.o test.s
>
> and disassembling:
>
> powerpc-linux-gnu-objdump -d test.o
>
> gives you:
>
> Disassembly of section .text:
>
> <.text>:
> 0: 10 07 4b 20 vmhaddshs v0,v7,v9,v12
> 4: 11 eb 03 21 vmhraddshs v15,v11,v0,v12
>
> but if you tell objdump to disassemble e500 instructions instead (use -M
> e500x2 to include e500v2 instructions):
>
> powerpc-linux-gnu-objdump -d -M e500 test.o
>
> you see:
>
> Disassembly of section .text:
>
> <.text>:
> 0: 10 07 4b 20 evstddx r0,r7,r9
> 4: 11 eb 03 21 evstdd r15,0(r11)
>
> The compiler is generating evstdd{,x} instructions, not vmhraddshs
> instructions.
>
> -Nathan
>
C++0X constexpr implementation status
Greetings, In my efforts to build C++-0X library components I've noticed that constexpr member variables are used in several places. I was unable to implement these as intended and reverted to const accessors. It seems like the intent is sort of a static const function except that it binds to a specific instance. I looked around and it looked like some effort had taken place to implement constexpr in the front end. I was wondering where this effort left off? Will it be picked up in the gcc-4.5 time frame? Thanks, Ed.
Re: How can I determine a register is referred through MEM at split2 stage?
"Guo, Xuepeng" writes: > I am working on an optimization which happens at split2 stage. I > need to determine whether the destination operand of the current RTL > (which is a register operand) will be referred by other RTL through > MEM within a basic block. I see there is a function named > reg_mentioned_p (const_rtx reg, const_rtx in) in rtlanal.c to show > whether REG appears somewhere within IN. It does help except that it > can't tell me whether IN refers REG through MEM. Can anyone give me > some suggestions? You're going to have to write your own walker. There isn't any generic code for this. Are you sure you've described what you want? It sounds sort of strange. Why should you care about an entire basic block and only a basic block? Ian
RE: How can I determine a register is referred through MEM at split2 stage?
Hi Ian, Thanks for your comments. It's not exactly the entire basic block. It should be from the current RTL to the end of the current basic block. As you know GCC will optimize "addl %ebx, %eax" to "leal (%ebx, %eax), %eax" to avoid the flag register dependency through a splitter in i386.md at split2 stage. But for my target, if the destination register of ADD actually holds non-address operand, which means "%eax" won't be used in MEM of the following RTL, this optimization will incur two cycles penalty. So I need to check whether the destination of ADD holds an address operands to decide whether split ADD to LEA. Thanks Xuepeng Guo -Original Message- From: Ian Lance Taylor [mailto:i...@google.com] Sent: 2008年12月17日 15:08 To: Guo, Xuepeng Cc: gcc@gcc.gnu.org; Lu, Hongjiu; Ye, Joey; Lin, Weiliang Subject: Re: How can I determine a register is referred through MEM at split2 stage? "Guo, Xuepeng" writes: > I am working on an optimization which happens at split2 stage. I > need to determine whether the destination operand of the current RTL > (which is a register operand) will be referred by other RTL through > MEM within a basic block. I see there is a function named > reg_mentioned_p (const_rtx reg, const_rtx in) in rtlanal.c to show > whether REG appears somewhere within IN. It does help except that it > can't tell me whether IN refers REG through MEM. Can anyone give me > some suggestions? You're going to have to write your own walker. There isn't any generic code for this. Are you sure you've described what you want? It sounds sort of strange. Why should you care about an entire basic block and only a basic block? Ian
Re: [avr]: potential runtime bug in insn andsi3?
2008/12/16 Georg-Johann Lay : > Hi, > > ./gcc/config/avr/avr.md > > defines andsi3 as follows: [...] > > For alternative 1 "d,0,i" the effect on cc_status is described as set_n. > However, if the high byte of [2] is 0xff, then the PSW (i.e. SREG.N) > does not contain the MSB of the result. > > I did not try to find a source that produces a bug basing on that, > but obviously the insn does not do what it states algebraically. > > Besides that, andhi3 says cc=clobber in the similar case "d,0,i", > which is correct IMHO. Thank you. Will be fixed tomorrow. Denis.
