[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[Joey dot ye at intel dot com]

--- Comment #47 from Joey dot ye at intel dot com  2009-03-12 06:51 ---
(In reply to comment #46)
> Created an attachment (id=17444)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17444&action=view) [edit]
> gcc.target/i386/stackalign/longlong-2.c for -mnostackalign on darwin10
> /sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/
> /sw/src/fink.build/gcc44-4.3.999-20090311/gcc-4.4-20090311/gcc/testsuite/gcc.target/i386/stackalign/longlong-2.c
> -mstackrealign -O2 -mpreferred-stack-boundary=2 -S -m32 -o longlong-2.s
That's because MacOS require stack alignment to 16 byte when making call and
ignores -mpreferred-stack-boundary=2. These cases should skipped for MacOS.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/36800] va_arg for _Decimal128 on 32-bit Power mishandled in certain cases

[bje at gcc dot gnu dot org]

-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-12 04:55:25
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36800

[Bug target/32542] When -msdata is set, gcc sent -memb to gas.

[bje at gcc dot gnu dot org]

-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-linux-gnu   |
   Last reconfirmed|-00-00 00:00:00 |2009-03-12 04:54:20
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32542

[Bug target/36425] Option -mno-isel not working

[bje at gcc dot gnu dot org]

--- Comment #7 from bje at gcc dot gnu dot org  2009-03-12 04:52 ---
A patch was checked in.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425

[Bug target/30451] incorrect attributes in *movti_ppc64 of rs6000.md

[bje at gcc dot gnu dot org]

-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-03-05 04:56:00 |2009-03-12 04:44:59
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30451

[Bug driver/39439] The Driver hides "undefined reference" messages from shared libs (but not object files) in linker phase

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-03-12 04:42 ---
Subject: Re:   New: The Driver hides "undefined reference" messages from shared
libs (but not object files) in linker phase



Sent from my iPhone

On Mar 11, 2009, at 9:27 PM, "rob1weld at aol dot com"
 wrote:

> The Driver hides "undefined reference" messages from shared libs but
> not from object files. This seems inconsistent and is not helpful.
>

Why do you think the driver is doing instead of the linker?

> When compiling 'ppl' using the Trunk I'm getting a terse message
> about "undefined reference to `typeinfo for int'". This is not
> particularly useful since the words are common (can't grep for
> them) and there is no line number info explaining the location of
> the code that causes this issue.
>
> This page may suggest a reason this error occurs:
> http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo
>
>
> I'm calling this an RFE since I desire an increase in verbosity
> but there are no doubt arguments favoring this being a Bug.
>
>
> # gcc -v
> Using built-in specs.
> Target: i386-pc-solaris2.11
> Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4
> --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
> --disable-static --enable-multilib --enable-decimal-float
> --with-long-double-128 --with-included-gettext --disable-stage1- 
> checking
> --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
> --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
> --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/ 
> local
> --without-ppl
> Thread model: posix
> gcc version 4.4.0 20090309 (experimental) [trunk revision 144720]  
> (GCC)
>
>
> # gmake
> ...
> gmake[4]: Entering directory `/usr/share/src/ppl-build/demos/ 
> ppl_lpsol'
> gcc -DHAVE_CONFIG_H -I. -I../../../ppl/demos/ppl_lpsol -I../..
> -I../../interfaces/C  -I/usr/local/include -pedantic -std=gnu89 - 
> Werror -g -O3
> -fomit-frame-pointer -march=k8 -frounding-math  -W -Wall -MT  
> ppl_lpsol.o -MD
> -MP -MF .deps/ppl_lpsol.Tpo -c -o ppl_lpsol.o
> ../../../ppl/demos/ppl_lpsol/ppl_lpsol.c
> mv -f .deps/ppl_lpsol.Tpo .deps/ppl_lpsol.Po
> /bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O3 -fomit- 
> frame-pointer
> -march=k8 -frounding-math  -W -Wall   -o ppl_lpsol ppl_lpsol.o  
> dummy.o -lglpk
> ../../interfaces/C/libppl_c.la -lm -L/usr/local/lib -lgmpxx -L/usr/ 
> local/lib
> -lgmp -R/usr/local/lib -R/usr/local/lib
> libtool: link: g++ -g -O3 -fomit-frame-pointer -march=k8 -frounding- 
> math -W
> -Wall -o .libs/ppl_lpsol ppl_lpsol.o dummy.o  /usr/local/lib/ 
> libglpk.so -lz
> ../../interfaces/C/.libs/libppl_c.so -L/usr/local/lib
> /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
> +.so
> /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so -lm
> /usr/local/lib/libgmp.so -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath
> -Wl,/usr/local/gcc4/lib
> ../../interfaces/C/.libs/libppl_c.so: undefined reference to  
> `typeinfo for int'
> collect2: ld returned 1 exit status
> gmake[4]: *** [ppl_lpsol] Error 1
> gmake[4]: Leaving directory `/usr/share/src/ppl-build/demos/ppl_lpsol'
>
>
> If I run that using "-v" I get this collect command:
>
> /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V -m  
> elf_i386
> -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
> /usr/lib/crti.o /usr/lib/values-Xa.o
> /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ 
> local/lib
> -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
> -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../..  
> ppl_lpsol.o
> dummy.o --verbose /usr/local/lib/libglpk.so -lz
> ../../interfaces/C/.libs/libppl_c.so
> /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
> +.so
> /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so
> /usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/ 
> gcc4/lib
> -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
> /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/ 
> crtn.o
>
>
> If I run that then I get this simple and useless output:
>
> ../../interfaces/C/.libs/libppl_c.so: undefined reference to  
> `typeinfo for int'
> collect2: ld returned 1 exit status
>
>
> If I run that exact same command but make a simple alteration:
> - ... -lz ../../interfaces/C/.libs/libppl_c.so
> + ... -lz ../../interfaces/C/.libs/*.o
>
> I can use the Object files that were used to create the Shared Library
> instead of using the Shared Library. This is useful (due to this
> Bug or needed RFE) since the error messages printed are by _far_ more
> useful, see:
>
> # /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V - 
> m elf_i386
> -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
> /usr/lib/crti.o /usr/lib/values-Xa.o
> /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ 
> local/lib
> -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4

Re: [Bug driver/39439] New: The Driver hides "undefined reference" messages from shared libs (but not object files) in linker phase

[Andrew Thomas Pinski]

Sent from my iPhone

On Mar 11, 2009, at 9:27 PM, "rob1weld at aol dot com" > wrote:



The Driver hides "undefined reference" messages from shared libs but
not from object files. This seems inconsistent and is not helpful.



Why do you think the driver is doing instead of the linker?


When compiling 'ppl' using the Trunk I'm getting a terse message
about "undefined reference to `typeinfo for int'". This is not
particularly useful since the words are common (can't grep for
them) and there is no line number info explaining the location of
the code that causes this issue.

This page may suggest a reason this error occurs:
http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo


I'm calling this an RFE since I desire an increase in verbosity
but there are no doubt arguments favoring this being a Bug.


# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --disable-stage1- 
checking

--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/ 
local

--without-ppl
Thread model: posix
gcc version 4.4.0 20090309 (experimental) [trunk revision 144720]  
(GCC)



# gmake
...
gmake[4]: Entering directory `/usr/share/src/ppl-build/demos/ 
ppl_lpsol'

gcc -DHAVE_CONFIG_H -I. -I../../../ppl/demos/ppl_lpsol -I../..
-I../../interfaces/C  -I/usr/local/include -pedantic -std=gnu89 - 
Werror -g -O3
-fomit-frame-pointer -march=k8 -frounding-math  -W -Wall -MT  
ppl_lpsol.o -MD

-MP -MF .deps/ppl_lpsol.Tpo -c -o ppl_lpsol.o
../../../ppl/demos/ppl_lpsol/ppl_lpsol.c
mv -f .deps/ppl_lpsol.Tpo .deps/ppl_lpsol.Po
/bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O3 -fomit- 
frame-pointer
-march=k8 -frounding-math  -W -Wall   -o ppl_lpsol ppl_lpsol.o  
dummy.o -lglpk
../../interfaces/C/libppl_c.la -lm -L/usr/local/lib -lgmpxx -L/usr/ 
local/lib

-lgmp -R/usr/local/lib -R/usr/local/lib
libtool: link: g++ -g -O3 -fomit-frame-pointer -march=k8 -frounding- 
math -W
-Wall -o .libs/ppl_lpsol ppl_lpsol.o dummy.o  /usr/local/lib/ 
libglpk.so -lz

../../interfaces/C/.libs/libppl_c.so -L/usr/local/lib
/usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
+.so

/usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so -lm
/usr/local/lib/libgmp.so -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath
-Wl,/usr/local/gcc4/lib
../../interfaces/C/.libs/libppl_c.so: undefined reference to  
`typeinfo for int'

collect2: ld returned 1 exit status
gmake[4]: *** [ppl_lpsol] Error 1
gmake[4]: Leaving directory `/usr/share/src/ppl-build/demos/ppl_lpsol'


If I run that using "-v" I get this collect command:

/usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V -m  
elf_i386

-Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/values-Xa.o
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ 
local/lib

-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../..  
ppl_lpsol.o

dummy.o --verbose /usr/local/lib/libglpk.so -lz
../../interfaces/C/.libs/libppl_c.so
/usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
+.so

/usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so
/usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/ 
gcc4/lib

-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/ 
crtn.o



If I run that then I get this simple and useless output:

../../interfaces/C/.libs/libppl_c.so: undefined reference to  
`typeinfo for int'

collect2: ld returned 1 exit status


If I run that exact same command but make a simple alteration:
- ... -lz ../../interfaces/C/.libs/libppl_c.so
+ ... -lz ../../interfaces/C/.libs/*.o

I can use the Object files that were used to create the Shared Library
instead of using the Shared Library. This is useful (due to this
Bug or needed RFE) since the error messages printed are by _far_ more
useful, see:

# /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V - 
m elf_i386

-Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/values-Xa.o
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ 
local/lib

-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../..  
ppl_lpsol.o

dummy.o /usr/local/lib/libglpk.so -lz   ../../interfaces/C/.libs/*.o
/usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
+.so

/usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so
/usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/ 
gcc4/lib

-lstdc++ -lm -lgcc_s -lgcc -lc -l

[Bug target/5267] invoke.texi "RS/6000 and PowerPC Options" list needs cleanup

[bje at gcc dot gnu dot org]

-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-09-24 17:07:04 |2009-03-12 04:41:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5267

[Bug driver/39439] New: The Driver hides "undefined reference" messages from shared libs (but not object files) in linker phase

[rob1weld at aol dot com]

The Driver hides "undefined reference" messages from shared libs but 
not from object files. This seems inconsistent and is not helpful.

When compiling 'ppl' using the Trunk I'm getting a terse message
about "undefined reference to `typeinfo for int'". This is not
particularly useful since the words are common (can't grep for
them) and there is no line number info explaining the location of
the code that causes this issue.

This page may suggest a reason this error occurs:
http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo


I'm calling this an RFE since I desire an increase in verbosity
but there are no doubt arguments favoring this being a Bug.


# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --disable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090309 (experimental) [trunk revision 144720] (GCC) 


# gmake
...
gmake[4]: Entering directory `/usr/share/src/ppl-build/demos/ppl_lpsol'
gcc -DHAVE_CONFIG_H -I. -I../../../ppl/demos/ppl_lpsol -I../.. 
-I../../interfaces/C  -I/usr/local/include -pedantic -std=gnu89 -Werror -g -O3
-fomit-frame-pointer -march=k8 -frounding-math  -W -Wall -MT ppl_lpsol.o -MD
-MP -MF .deps/ppl_lpsol.Tpo -c -o ppl_lpsol.o
../../../ppl/demos/ppl_lpsol/ppl_lpsol.c
mv -f .deps/ppl_lpsol.Tpo .deps/ppl_lpsol.Po
/bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O3 -fomit-frame-pointer
-march=k8 -frounding-math  -W -Wall   -o ppl_lpsol ppl_lpsol.o dummy.o -lglpk
../../interfaces/C/libppl_c.la -lm -L/usr/local/lib -lgmpxx -L/usr/local/lib
-lgmp -R/usr/local/lib -R/usr/local/lib 
libtool: link: g++ -g -O3 -fomit-frame-pointer -march=k8 -frounding-math -W
-Wall -o .libs/ppl_lpsol ppl_lpsol.o dummy.o  /usr/local/lib/libglpk.so -lz
../../interfaces/C/.libs/libppl_c.so -L/usr/local/lib
/usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc++.so
/usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so -lm
/usr/local/lib/libgmp.so -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath
-Wl,/usr/local/gcc4/lib
../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int'
collect2: ld returned 1 exit status
gmake[4]: *** [ppl_lpsol] Error 1
gmake[4]: Leaving directory `/usr/share/src/ppl-build/demos/ppl_lpsol'


If I run that using "-v" I get this collect command:

/usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V -m elf_i386
-Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/values-Xa.o
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/local/lib
-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../.. ppl_lpsol.o
dummy.o --verbose /usr/local/lib/libglpk.so -lz
../../interfaces/C/.libs/libppl_c.so
/usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc++.so
/usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so
/usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/gcc4/lib
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/crtn.o


If I run that then I get this simple and useless output:

../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int'
collect2: ld returned 1 exit status


If I run that exact same command but make a simple alteration:
- ... -lz ../../interfaces/C/.libs/libppl_c.so
+ ... -lz ../../interfaces/C/.libs/*.o

I can use the Object files that were used to create the Shared Library
instead of using the Shared Library. This is useful (due to this
Bug or needed RFE) since the error messages printed are by _far_ more
useful, see:

# /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V -m elf_i386
-Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/values-Xa.o
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/local/lib
-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
-L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../.. ppl_lpsol.o
dummy.o /usr/local/lib/libglpk.so -lz   ../../interfaces/C/.libs/*.o   
/usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc++.so
/usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so
/usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/gcc4/lib
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/crtn.o
GNU ld (GNU Binutils) 2.19.1
  Supported emulations:
   elf_i386_ldso
   elf_i386
   elf_x86_64
../../interfaces/C/.libs/ppl_c__BD_S

Re: [Bug c/38286] configure: error: cannot compute suffix of object files - cannot find as

[tmpAsk]

Hi. Since I'm the administrator of my server, I have installed gmp4.2.1
mpfr2.4.1 and then installing GCC4.3.2 and get the same result of Bugzilla
from gcc-bugzi...@gcc.gnu.org.  After installing binutils 2.1.9, I still get
the same error message of following 


-B/home/users/EDA/eda02/openMP_test/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/
-B/home/users/EDA/eda02/openMP_test/gcc-4.3.2-build/x86_64-unknown-linux-gnu/bin/
-B/home/users/EDA/eda02/openMP_test/gcc-4.3.2-build/x86_64-unknown-linux-gnu/lib/
-isystem
/home/users/EDA/eda02/openMP_test/gcc-4.3.2-build/x86_64-unknown-linux-gnu/include
-isystem
/home/users/EDA/eda02/openMP_test/gcc-4.3.2-build/x86_64-unknown-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.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/users/EDA/eda02/openMP_test/gcc-4.3.2'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/users/EDA/eda02/openMP_test/gcc-4.3.2'
make: *** [all] Error 2

I guess the GCC does not know I have installed a new binutils due to the
configure 
"
./configure --prefix=/home/users/EDA/eda02/openMP_test/gcc-4.3.2-build
--enable-threads=posix--with-system-zlib --enable-languages=c,c++
--with-gmp=/home/users/EDA/eda02/openMP_test/gmp421
--with-mpfr=/home/users/EDA/eda02/openMP_test/mpfr241
LD_LIBRARY_PATH=/home/users/EDA/eda02/openMP_test/gcc-4.3.2-build/lib
" 
how can I make GCC know that there is a new binutils on other dir ??? 


THX for any response. 















Bugzilla from gcc-bugzi...@gcc.gnu.org wrote:
> 
> 
> 
> --- Comment #1 from brian at dessent dot net  2008-11-27 11:29 ---
> Subject: Re:   New: configure: error: cannot compute suffix of 
>  object files - cannot find as
> 
> The assembler is not part of gcc.  You need to build and install
> binutils for your target (which will result in the cross-assembler and
> cross-linker) before attempting to build the compiler.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38286
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-Bug-c-38286---New%3A-configure%3A-error%3A-cannot-compute-suffix-of-object-files---cannot-find-as-tp20717408p22469444.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug c++/39429] compiler create bad asm codes.

[ryos at sinby dot com]

--- Comment #1 from ryos at sinby dot com  2009-03-12 01:19 ---
Created an attachment (id=17445)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17445&action=view)
test sources

this is test sources.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[howarth at nitro dot med dot uc dot edu]

--- Comment #46 from howarth at nitro dot med dot uc dot edu  2009-03-12 
00:46 ---
Created an attachment (id=17444)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17444&action=view)
gcc.target/i386/stackalign/longlong-2.c for -mnostackalign on darwin10

/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20090311/gcc-4.4-20090311/gcc/testsuite/gcc.target/i386/stackalign/longlong-2.c
-mstackrealign -O2 -mpreferred-stack-boundary=2 -S -m32 -o longlong-2.s


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[howarth at nitro dot med dot uc dot edu]

--- Comment #45 from howarth at nitro dot med dot uc dot edu  2009-03-12 
00:45 ---
Created an attachment (id=17443)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17443&action=view)
gcc.target/i386/stackalign/longlong-2.c for -mstackalign on darwin10

/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20090311/gcc-4.4-20090311/gcc/testsuite/gcc.target/i386/stackalign/longlong-2.c
-mstackrealign -O2 -mpreferred-stack-boundary=2 -S -m32 -o longlong-2.s


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[hjl dot tools at gmail dot com]

--- Comment #44 from hjl dot tools at gmail dot com  2009-03-12 00:44 
---
Those tests should be skipped on MacOS since it ignores
-mpreferred-stack-boundary=2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[howarth at nitro dot med dot uc dot edu]

--- Comment #43 from howarth at nitro dot med dot uc dot edu  2009-03-12 
00:41 ---
On darwin10, I am seeing...

Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20090311/gcc-4.4-20090311/gcc/testsuite/gcc.target/i386/stackalign/longlong-2.c
 -mstackrealign -O2 -mpreferred-stack-boundary=2 -S  -m32 -o longlong-2.s   
(timeout = 300)
PASS: gcc.target/i386/stackalign/longlong-2.c -mstackrealign (test for excess
errors)
FAIL: gcc.target/i386/stackalign/longlong-2.c scan-assembler-times
and[lq]?[^\n]*-8,[^\n]*sp 2
FAIL: gcc.target/i386/stackalign/longlong-2.c scan-assembler-times
and[lq]?[^\n]*-16,[^\n]*sp 2

and

Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20090311/gcc-4.4-20090311/gcc/testsuite/gcc.target/i386/stackalign/longlong-2.c
 -mno-stackrealign -O2 -mpreferred-stack-boundary=2 -S  -m32 -o longlong-2.s   
(timeout = 300)
PASS: gcc.target/i386/stackalign/longlong-2.c -mno-stackrealign (test for
excess errors)
FAIL: gcc.target/i386/stackalign/longlong-2.c scan-assembler-times
and[lq]?[^\n]*-8,[^\n]*sp 2
FAIL: gcc.target/i386/stackalign/longlong-2.c scan-assembler-times
and[lq]?[^\n]*-16,[^\n]*sp 2

The assembly from each is attached.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug middle-end/39378] Multiple inheritence thunk not working with -mthumb

[ramana dot r at gmail dot com]

--- Comment #1 from ramana dot r at gmail dot com  2009-03-11 23:30 ---
Patch submitted at http://gcc.gnu.org/viewcvs?view=rev&revision=143367


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39378

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2009-03-11 23:24 ---
The problem is that the memory_operand in the insns also needs registers, and
as the insn before RA has (mem:DI (plus:SI (reg:SI reg1) (reg:SI reg2))), it
needs
2 registers, not just one or zero.  And that is already one too much.  I'd say
we need to handle only a subset of valid memory_operand operands in these 2
patterns, those that need zero or one register.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-11 17:50:57 |2009-03-11 23:24:02
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2009-03-11 22:58 ---
If it's too hard to make the test work reliably, may be just XFAIL them or
deactivate them until someone comes up with a more reliable way?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697

[Bug c/39438] New: Can't compile a wrapper around strftime with -Werror=format-nonliteral

[4tmuelle at informatik dot uni-hamburg dot de]

I basically have a wrapper around strftime() and compilation with
-Werror=format-nonliteral fails when the wrapper wants to call strftime,
because "format not a string literal, format string not checked". 



The code in question looks like this:



#include
#include

#define SIZE 256

size_t my_strftime(char *s, size_t max, const char *fmt,
   const struct tm *tm)
{
size_t ret;
ret = strftime(s, max, fmt, tm);
return ret;
}

int
main ()
{
char s[SIZE];
time_t curtime;
struct tm* loctime;

curtime = time(NULL);
loctime = localtime (&curtime);
my_strftime(s, SIZE, "Hello %A", loctime);
printf("%s", s);
return 0;
} 



mue...@bigbox /tmp $ gcc -v -save-temp -Wformat  -Wformat-nonliteral
-Werror=format-nonliteral -o mystrftime{,.c} 
Using built-in specs.
gcc: unrecognized option '-save-temp'
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temp' '-Wformat' '-Wformat-nonliteral'
'-Werror=format-nonliteral' '-o' 'mystrftime' '-mtune=generic'
 /usr/libexec/gcc/x86_64-redhat-linux/4.3.2/cc1 -quiet -v mystrftime.c -quiet
-dumpbase mystrftime.c -mtune=generic -auxbase mystrftime -Wformat
-Wformat-nonliteral -Werror=format-nonliteral -version -o /tmp/ccznk3Wo.s
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.3.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.3.2/include
 /usr/include
End of search list.
GNU C (GCC) version 4.3.2 20081105 (Red Hat 4.3.2-7) (x86_64-redhat-linux)
compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c99c7b3dc8e919a4b394102437269a84
mystrftime.c: In function ‘my_strftime’:
mystrftime.c:14: error: format not a string literal, format string not checked
mue...@bigbox /tmp $ 


I raised this issue on gcc-help (Message-ID:
<49a96972.5060...@informatik.uni-hamburg.de>) and got the tip to use 
__attribute__(( format(strftime, 3, 0) )) but it doesn't work.


I think I want to make gcc
 * know that the wrapper is not responsible for the format string and
   thus the call to strftime is allowed
 * pass the responsibility up to the callers and thus check whether they
   call the wrapper with "good" strings.

but it doesn't seem possible.


I hope to have all needed information included. I can't, however, fulfil the
request from http://gcc.gnu.org/bugs.html to attach *.*i* files, because there
are none. Also, I searched the bugzilla for "format-nonliteral" and found
nothing related to this issue. I thus think it hasn't been filed yet.


-- 
   Summary: Can't compile a wrapper around strftime with -
Werror=format-nonliteral
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4tmuelle at informatik dot uni-hamburg dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2009-03-11 22:43 ---
Subject: Re:  gcc.target/arm/neon/neon.exp tests for vmov
 fail on arm-linux-eabi

On Wed, 11 Mar 2009, jules at gcc dot gnu dot org wrote:

> These failures show up because the tests are kind of weak. There's no
> particular reason that vget_low* intrinsics should generate vmov instructions
> as the tests are expecting: the assembly output shown with vldr/fstd works 
> just
> as well, and no instructions at all (i.e. just a hint to the register
> allocator) would work even better.

That's the move intrinsic tests.  I think polytypes.c is because of 
additional diagnostics added at some point for which target-independent 
tests were updated but not all target-specific tests (i.e., the testcase 
needs updating for the current front-end diagnostics).  Unlike the move 
instrinsics tests polytypes.c is not an automatically generated file, so 
should be straightforward for anyone to fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-03-11 22:41 ---
Confirm; this F2003 feature is not yet implemented.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 22:41:58
   date||
Summary|Error on generic name   |F2003: Procedures with same
   |equivalent to type name in  |name as types/type
   |same module |constructors


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427

[Bug c++/26965] [4.2/4.3/4.4 Regression] Unnecessary debug info for unused consts in C++

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-03-11 21:54 
---
Honza, maybe you want to have a look here ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug c++/39437] New: Support for automatic linking via pragma

[olafvdspek at gmail dot com]

MSVC supports the following pragma, which can be used to automatically link a
library when a header file is included. This is used by for example Boost.

#pragma comment(lib, "requiredLibrary.lib")

Unfortunately, g++ doesn't support this. Could you add it?


-- 
   Summary: Support for automatic linking via pragma
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olafvdspek at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437

[Bug c++/39425] [4.2/4.3/4.4 Regression] gcc loops after reporting template instantiation errors

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39425

[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[jakub at gcc dot gnu dot org]

--- Comment #42 from jakub at gcc dot gnu dot org  2009-03-11 21:23 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[jakub at gcc dot gnu dot org]

--- Comment #41 from jakub at gcc dot gnu dot org  2009-03-11 21:12 ---
Subject: Bug 39137

Author: jakub
Date: Wed Mar 11 21:12:33 2009
New Revision: 144792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144792
Log:
PR target/39137
* cfgexpand.c (get_decl_align_unit): Use LOCAL_DECL_ALIGNMENT
macro.
* defaults.h (LOCAL_DECL_ALIGNMENT): Define if not yet defined.
* config/i386/i386.h (LOCAL_DECL_ALIGNMENT): Define.
* config/i386/i386.c (ix86_local_alignment): For
-m32 -mpreferred-stack-boundary=2 use 32-bit alignment for
long long variables on the stack to avoid dynamic realignment.
Allow the first argument to be a decl rather than type.
* doc/tm.texi (LOCAL_DECL_ALIGNMENT): Document.

* gcc.target/i386/stackalign/longlong-1.c: New test.
* gcc.target/i386/stackalign/longlong-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/stackalign/longlong-1.c
trunk/gcc/testsuite/gcc.target/i386/stackalign/longlong-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/defaults.h
trunk/gcc/doc/tm.texi
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-03-11 21:09 ---
Yeah, sync_double_compare_and_swapdi_pic and
sync_double_compare_and_swap_ccdi_pic insns are a little bit register hungry,
they need %eax, %edx, %ecx and one of %esi or %edi.  %ebx is reserved for PIC
pointer, without -fomit-frame-pointer %ebp is reserved as well, %esp is
reserved, so only one of %esi and %edi is left for other stuff.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 21:08:38
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-11 20:51 ---
Well, certainlu with i?86 and -fPIC there are not many registers available.
Using -fomit-frame-pointer may "fix" this issue in this particular case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi

[jules at gcc dot gnu dot org]

--- Comment #3 from jules at gcc dot gnu dot org  2009-03-11 20:47 ---
These failures show up because the tests are kind of weak. There's no
particular reason that vget_low* intrinsics should generate vmov instructions
as the tests are expecting: the assembly output shown with vldr/fstd works just
as well, and no instructions at all (i.e. just a hint to the register
allocator) would work even better.

Without converting all the Neon intrinsic tests to be execution rather than
compilation tests, I'm not sure if there's any way they can be made robust.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697

[Bug c++/39425] [4.2/4.3/4.4 Regression] gcc loops after reporting template instantiation errors

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-03-11 20:32 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00570.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||03/msg00570.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39425

[Bug bootstrap/39398] verify_flow_info failed

[terminatorul at gmail dot com]

--- Comment #3 from terminatorul at gmail dot com  2009-03-11 20:15 ---
If I compile gcc without an -O option in my CFALGS/CXXFLAGS than it works fine
and I could install gcc 4.3.3

If I compile with -O2 instead of -O3 in my CFLAGS it would still not work.

I tried to bootstrap again, with the newly installed gcc 4.3.3 and -O3, and the
bug is still there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39398

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[rguenth at gcc dot gnu dot org]

--- Comment #40 from rguenth at gcc dot gnu dot org  2009-03-11 20:04 
---
Both patches look ok to me.  For 4.5 we might want to consider merging
some of the target hooks though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-03-11 19:38 ---
I can confirm that trunk with the #c1 patch modified as mentioned in #c3 cures
all the gdb.base/store.exp failures.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug c/39433] ICE on header file conflict with -fstack-protector

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-03-11 19:31 ---
Trunk is fine.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.1.2 4.3.3
  Known to work||4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39433

[Bug c/39433] ICE on header file conflict with -fstack-protector

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-03-11 19:29 ---
You need -fstack-protector to see ICE.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 19:29:21
   date||
Summary|gcc core dumping for|ICE on header file conflict
   |unnecessary header file |with -fstack-protector
   |conflict|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39433

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-03-11 18:53 ---
This is actually a general reload problem that will be more and more visible,
as register pressure goes up due to increased register life times (due to other
optimization passes).

Search for "spill" in the bugzilla returns 20 bugs, where 14 bugs are
describing similar failure:

PR 12958 Spill failure when compiling FLAC
PR 16185 ICE: in spill_failure, at reload1.c:1892, global register...
PR 9085  Unable to find register to spill when optimizing
PR 32647 spill failures with hard-register variable
PR 35135 unable to find a register to spill in class ‘GENERAL_REGS...
PR 35664 unable to find a register to spill in class 'FP_REGS' (sp...
PR 36680 ICE in spill_failure, reload1.c:1995
PR 38403 unable to find a register to spill in class ‘CREG’ with -...
PR 38900 unable to find a register to spill
PR 39212 ice for AVR target: unable to find a register to spill in...
PR 39431 [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093
PR 38621 [4.3/4.4 Regression] sh gcc unable to spill register when...
PR 24319 [4.2/4.3/4.4 regression] amd64 register spill error with ...
PR 31786 [4.2/4.3/4.4 Regression][avr] error: unable to find a reg... 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug c++/39425] [4.2/4.3/4.4 Regression] gcc loops after reporting template instantiation errors

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-03-11 18:23 ---
I think this is introduced by revision 117206

http://gcc.gnu.org/ml/gcc-cvs/2006-09/msg00593.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||lmillward at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39425

[Bug debug/30161] GCC should generate dwarf info about template parameters

[dodji at gcc dot gnu dot org]

--- Comment #6 from dodji at gcc dot gnu dot org  2009-03-11 17:54 ---
Quick Status of
http://people.redhat.com/~dseketel/gcc/PR30161/PR30161-patch-v4.txt:

The patch generates DW_TAG_template_type_param and DW_TAG_template_value_param
for template type parameters as well as non-type parameters. Debug info for
template parameter packs (parameters of variadic templates) are also generated.

Template template parameters are not supported as it seems the DWARF3 spec
doesn't support those. Please look at the examples at the end of the patch to
see the type of template parameters for which debug info is generated by the
patch today.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-03-11 17:50 ---
This bug is introduced by revision 128012:

http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg6.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 17:50:57
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug c/39433] gcc core dumping for unnecessary header file conflict

[nmdilipsimha at gmail dot com]

--- Comment #2 from nmdilipsimha at gmail dot com  2009-03-11 17:48 ---
(In reply to comment #1)
> It doesn't segfault for me (gcc version 4.1.3 20080704 (prerelease) (Debian
> 4.1.2-25)
> 

hmm.
Mine is:

si...@home_pc:~/test/header_file$ 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.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)


Core file:
si...@home_pc:~/test/header_file$ gdb gcc core
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)

warning: core file may not match specified executable file.
(no debugging symbols found)
(no debugging symbols found)
Core was generated by `/usr/lib/gcc/i486-linux-gnu/4.1.3/cc1 -quiet 1.c -quiet
-dumpbase 1.c -mtune=ge'.
Program terminated with signal 11, Segmentation fault.
[New process 23070]
#0  0x0836a480 in ?? ()

Couldn't debug much into this. No symbols are present.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39433

[Bug debug/39436] New: g++ does not emit DW_TAG_try_block or DW_TAG_catch_block

[tromey at gcc dot gnu dot org]

g++ does not emit DW_TAG_try_block or DW_TAG_catch_block.
It probably should.


-- 
   Summary: g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

[vmakarov at redhat dot com]

--- Comment #5 from vmakarov at redhat dot com  2009-03-11 17:28 ---
As for DECL_HARD_REGISTER, such decl regs are never considered by IRA for
allocation.   So I think there is no necessity to check them here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[hjl dot tools at gmail dot com]

--- Comment #39 from hjl dot tools at gmail dot com  2009-03-11 17:17 
---
(In reply to comment #38)
> Created an attachment (id=17442)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17442&action=view) [edit]
> gcc44-pr39137-2.patch
> 
> Alternative patch which does stack realignment in f[2345] rather than just in
> f[345].
> 

That is very nice. Can you add testcases for f[2345]? Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug debug/30161] GCC should generate dwarf info about template parameters

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-03-11 17:16 ---
Work in progress patches are now at
http://people.redhat.com/~dseketel/gcc/PR30161


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[jakub at gcc dot gnu dot org]

--- Comment #38 from jakub at gcc dot gnu dot org  2009-03-11 17:14 ---
Created an attachment (id=17442)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17442&action=view)
gcc44-pr39137-2.patch

Alternative patch which does stack realignment in f[2345] rather than just in
f[345].


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-03-11 17:11 ---
Also perhaps should test DECL_HARD_REGISTER, for DECL_HARD_REGISTER we
shouldn't limit them in any way to allow the user to shoot himself.

In any case, I'll test your patch momentarily.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

[vmakarov at redhat dot com]

--- Comment #3 from vmakarov at redhat dot com  2009-03-11 17:10 ---
Thanks, Richard.

So instead of "DECL_NAME (decl) != NULL" I should use "! DECL_ARTIFICIAL
(decl)".  Right?

Ok, I'll test the new patch then and send it for approval after testing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug target/39431] [4.3/4.4 Regression] ICE in spill_failure, at reload1.c:2093

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 regression ICE in  |[4.3/4.4 Regression] ICE in
   |spill_failure, at   |spill_failure, at
   |reload1.c:2093  |reload1.c:2093
   Target Milestone|--- |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-03-11 17:02 ---
You should use DECL_ARTIFICIAL I think.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug c/39433] gcc core dumping for unnecessary header file conflict

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-11 17:00 ---
It doesn't segfault for me (gcc version 4.1.3 20080704 (prerelease) (Debian
4.1.2-25)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet| i486-linux-gnu |i486-linux-gnu
   GCC host triplet| i486-linux-gnu |i486-linux-gnu
 GCC target triplet| i486-linux-gnu |i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39433

[Bug c/39435] invalid assembly produced with -mpowerpc64 -Wa,-mppc64 -mcpu=970

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-03-11 16:59 ---
Sounds like a user error.  If you compile with -mcpu=970, you shouldn't be
telling the assembler not to grok power4 or altivec instructions, which it can
generate.  Just drop that -Wa,-mppc64, gcc will take care of passing the right
options to gas.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39435

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #18 from nickc at redhat dot com  2009-03-11 16:59 ---
Hi Guys,

  I have checked in a patch to add descriptions of the MCore options.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #17 from nickc at redhat dot com  2009-03-11 16:57 ---
Created an attachment (id=17441)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17441&action=view)
Add descriptions of MCore options


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures

[vmakarov at redhat dot com]

--- Comment #1 from vmakarov at redhat dot com  2009-03-11 16:57 ---
Jakub, how is about the following patch.  Is it ok for you?  I mean correct
user variable identification.

2009-03-11  Vladimir Makarov  

PR debug/39432
* ira-int.h (struct allocno): Fix comment for calls_crossed_num.
* ira-conflicts.c (ira_build_conflicts): Prohibit call used
registers for allocnos created from user-defined variables.

Index: ira-int.h
===
--- ira-int.h   (revision 144543)
+++ ira-int.h   (working copy)
@@ -333,7 +333,7 @@ struct ira_allocno
   /* Accumulated frequency of calls which given allocno
  intersects.  */
   int call_freq;
-  /* Length of the previous array (number of the intersected calls).  */
+  /* Accumulated number of the intersected calls.  */
   int calls_crossed_num;
   /* Non NULL if we remove restoring value from given allocno to
  MEM_OPTIMIZED_DEST at loop exit (see ira-emit.c) because the
Index: ira-conflicts.c
===
--- ira-conflicts.c (revision 144543)
+++ ira-conflicts.c (working copy)
@@ -800,29 +800,33 @@ ira_build_conflicts (void)
 }
   FOR_EACH_ALLOCNO (a, ai)
 {
-  if (ALLOCNO_CALLS_CROSSED_NUM (a) == 0)
-   continue;
-  if (! flag_caller_saves)
+  reg_attrs *attrs;
+  tree decl;
+
+  if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
+ /* For debugging purposes don't put user defined variables in
+callee-clobbered registers.  */
+ || (optimize <= 1
+ && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) !=
NULL
+ && (decl = attrs->decl) != NULL
+ && VAR_OR_FUNCTION_DECL_P (decl)
+ && DECL_NAME (decl) != NULL))
{
  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
call_used_reg_set);
- if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
-   IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
- call_used_reg_set);
+ IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
+   call_used_reg_set);
}
-  else
+  else if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
{
  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
no_caller_save_reg_set);
  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
temp_hard_reg_set);
- if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
-   {
- IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
-   no_caller_save_reg_set);
- IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
-   temp_hard_reg_set);
-   }
+ IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
+   no_caller_save_reg_set);
+ IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
+   temp_hard_reg_set);
}
 }
   if (optimize && ira_conflicts_p




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug target/5362] Undocumented target options

[nickc at gcc dot gnu dot org]

--- Comment #16 from nickc at gcc dot gnu dot org  2009-03-11 16:57 ---
Subject: Bug 5362

Author: nickc
Date: Wed Mar 11 16:57:01 2009
New Revision: 144783

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144783
Log:
PR target/5362
* config/mcore/mcore.opt: Remove deprecated m4align and m8align
options.
Add description to mno-lsim option.
* config/mcore/mcore.h: Remove comment about deprecated m4align
option.
(TARGET_DEFAULT): Remove deprecated MASK_M8ALIGN.
* doc/invoke.texi: Add description of mno-lsim and
mstack-increment options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mcore/mcore.h
trunk/gcc/config/mcore/mcore.opt
trunk/gcc/doc/invoke.texi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug c/39435] invalid assembly produced with -mpowerpc64 -Wa,-mppc64 -mcpu=970

[zimmerma+gcc at loria dot fr]

--- Comment #1 from zimmerma+gcc at loria dot fr  2009-03-11 16:51 ---
This problem was discovered while trying to compile GMP with ABI=mode32:
http://gmplib.org/list-archives/gmp-bugs/2009-March/001307.html

If either one of the three options -mpowerpc64 -Wa,-mppc64 -mcpu=970 is
removed,
the compilation works.


-- 

zimmerma+gcc at loria dot fr changed:

   What|Removed |Added

 CC||zimmerma+gcc at loria dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39435

[Bug c/39435] New: invalid assembly produced with -mpowerpc64 -Wa,-mppc64 -mcpu=970

[zimmerma+gcc at loria dot fr]

The following code gives:

zimme...@gcc40:~$ /opt/cfarm/release/4.3.3/bin/gcc -mpowerpc64 -Wa,-mppc64
-mcpu=970 -c bug.c
/tmp/ccCzXnwd.s: Assembler messages:
/tmp/ccCzXnwd.s:24: Error: junk at end of line: `1'

zimme...@gcc40:~$ cat bug.c
typedef unsigned long long int mp_limb_t;
typedef const mp_limb_t *mp_srcptr;
typedef long int mp_size_t;
void
foo (mp_srcptr src, mp_limb_t divisor)
{
  mp_limb_t h, s;
  mp_limb_t p0;
  for (;;)
{
  s = src[0];
  h = bar (&p0, divisor > s, divisor);
}
}


-- 
   Summary: invalid assembly produced with -mpowerpc64 -Wa,-mppc64 -
mcpu=970
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zimmerma+gcc at loria dot fr
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc970-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39435

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[jakub at gcc dot gnu dot org]

--- Comment #37 from jakub at gcc dot gnu dot org  2009-03-11 16:26 ---
Created an attachment (id=17440)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17440&action=view)
gcc44-pr39137.patch

Patch I'm going to bootstrap/regtest now.  I've re-added the TYPE_USER_ALIGN
check, because it fixes the f3 function in:
/* { dg-options "-Os -m32 -mpreferred-stack-boundary=2" } */

void fn (void *);

void f1 (void)
{
  unsigned long long a;
  fn (&a);
}

void f2 (void)
{
  unsigned long long a __attribute__((aligned (8)));
  fn (&a);
}

void f3 (void)
{
  typedef unsigned long long L __attribute__((aligned (8)));
  L a;
  fn (&a);
}

void f4 (void)
{
  unsigned long long a __attribute__((aligned (16)));
  fn (&a);
}

void f5 (void)
{
  typedef unsigned long long L __attribute__((aligned (16)));
  L a;
  fn (&a);
}

To cure even f2, we'd have to invent a new macro (LOCAL_DATA_ALIGNMENT), which
would be passed the DECL instead of type (in i386 case both could just call
ix86_local_alignment and if the first argument is non-NULL, if could just use
DECL_P vs. TYPE_P to find out if it is a decl or type).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug fortran/36704] Procedure pointer as function result

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-03-11 16:26 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-03/msg00044.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704

[Bug fortran/38290] procedure pointer assignment checking

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2009-03-11 16:23 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-12/msg00191.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290

[Bug fortran/39414] PROCEDURE statement double declaration bug

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-03-11 16:19 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-03/msg00028.html


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 16:19:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39414

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #15 from nickc at redhat dot com  2009-03-11 16:09 ---
Hi Guys,

  I have checked in a patch to add documentation for the FR30 target options.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #14 from nickc at redhat dot com  2009-03-11 16:09 ---
Created an attachment (id=17439)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17439&action=view)
Document the FR30 target options


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/5362] Undocumented target options

[nickc at gcc dot gnu dot org]

--- Comment #13 from nickc at gcc dot gnu dot org  2009-03-11 16:09 ---
Subject: Bug 5362

Author: nickc
Date: Wed Mar 11 16:08:41 2009
New Revision: 144780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144780
Log:
PR target/5362
* config/fr30/fr30.opt: Document the -mno-lsim option.
* doc/invoke.texi: Add descriptions of the FR30's -msmall-model
and -mno-lsim options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/fr30/fr30.opt
trunk/gcc/doc/invoke.texi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[rguenth at gcc dot gnu dot org]

--- Comment #36 from rguenth at gcc dot gnu dot org  2009-03-11 14:47 
---
In reply to comment #34, we should be able to fixup alignment in
get_decl_align_unit if DECL_USER_ALIGN is set (or change the prototype
for LOCAL_ALIGNMENT to take a decl and/or a type).

I wonder why we have both LOCAL_ALIGNMENT and STACK_SLOT_ALIGNMENT anyway...

but, Jakub, will you test & submit your patch from comment #32?

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug c/39433] New: gcc core dumping for unnecessary header file conflict

[nmdilipsimha at gmail dot com]

I created a small dummy program with a dedicated insignificant bug.
But gcc throws an error and then core dumps, which is abnormal.

Here is the output:
gcc -v -save-temps 1.c >& log.txt

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.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
 /usr/lib/gcc/i486-linux-gnu/4.1.3/cc1 -E -quiet -v 1.c -mtune=generic
-fpch-preprocess -o 1.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.3/cc1 -fpreprocessed 1.i -quiet -dumpbase 1.c
-mtune=generic -auxbase 1 -version -fstack-protector -fstack-protector -o 1.s
GNU C version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
(i486-linux-gnu)
compiled by GNU C version 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2).
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31866
Compiler executable checksum: caf034d6752b947185f431aa3e927159
In file included from 3.h:6,
 from 2.h:6,
 from 1.h:5,
 from 1.c:2:
1.h:3: error: redefinition of typedef ‘F1’
1.h:3: error: previous declaration of ‘F1’ was here
In file included from 3.h:6,
 from 2.h:6,
 from 1.h:5,
 from 1.c:2:
1.h:9: error: field ‘a2’ has incomplete type
In file included from 1.c:2:
1.h:7: error: redefinition of ‘struct f1’
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.

Since test program is very small, I am pasting it here:
source files:
si...@home_pc:~/test/header_file$ cat 1.c
#include "1.h"

int main()
{
F1 a;
a.a = 1;
return 0;
}

-
si...@home_pc:~/test/header_file$ cat 1.h
#ifndef F1_H

typedef struct f1 F1;
#include "2.h"

struct f1
{
int a;
F2 a2;
};

#define F1_H
#endif

-
si...@home_pc:~/test/header_file$ cat 2.h
#ifndef F2_H
#define F2_H

typedef struct f2 F2;
#include "3.h"

struct f2
{
int a;
F3 a3;
};

#endif

-
si...@home_pc:~/test/header_file$ cat 3.h
#ifndef F3_H
#define F3_H

typedef struct f3 F3;
#include "1.h"

struct f3
{
int a;
F1 a1;
};

#endif

-

Finally 1.i:
si...@home_pc:~/test/header_file$ cat 1.i
# 1 "1.c"
# 1 ""
# 1 ""
# 1 "1.c"
# 1 "1.h" 1


typedef struct f1 F1;
# 1 "2.h" 1



typedef struct f2 F2;
# 1 "3.h" 1



typedef struct f3 F3;
# 1 "1.h" 1


typedef struct f1 F1;
# 1 "2.h" 1
# 5 "1.h" 2

struct f1
{
 int a;
 F2 a2;
};
# 6 "3.h" 2

struct f3
{
 int a;
 F1 a1;
};
# 6 "2.h" 2

struct f2
{
 int a;
 F3 a3;
};
# 5 "1.h" 2

struct f1
{
 int a;
 F2 a2;
};
# 2 "1.c" 2

int main()
{
 F1 a;
 a.a = 1;
 return 0;
}


-- 
   Summary: gcc core dumping for unnecessary header file conflict
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmdilipsimha at gmail dot com
 GCC build triplet:  i486-linux-gnu
  GCC host triplet:  i486-linux-gnu
GCC target triplet:  i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39433

[Bug libstdc++/34106] [parallel mode] Atomic operations compatibility layer needs cleanup

[jwakely dot gcc at gmail dot com]

--- Comment #1 from jwakely dot gcc at gmail dot com  2009-03-11 14:29 
---
Created an attachment (id=17438)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17438&action=view)
remove support for other compilers

this patch re-implements the parallel mode's atomic operations in terms of the
GCC builtins


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106

[Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures

[jakub at gcc dot gnu dot org]

Running ../../../gdb/testsuite/gdb.base/store.exp ...
FAIL: gdb.base/store.exp: upvar charest l; print old l, expecting -1 .*
FAIL: gdb.base/store.exp: upvar short l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar int l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar long l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar longest l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar doublest l; print old l, expecting -1

are new failures in gdb testsuite when compiled with 4.4 compared to store.c
compiled with 4.3.x.  The difference seems to be introduced by IRA, when
compiled with -fno-ira (when trunk still had that option) the test worked.

With the old RA, -g -O0 -dA -fverbose-asm compiled:
unsigned int foo (unsigned int, unsigned int);

unsigned int bar (register unsigned int a, register unsigned int b)
{
  register unsigned int c = a, d = b;
  c = foo (c, d);
  return c + d;
}

d is allocated in a call-saved register (%ebx), which is fine and c is assigned
a stack slot.  With IRA d is still allocated in %ebx, but c is in %eax,
call-clobbered register.  So when gdb in the foo call does up and checks the
value in c and d, it finds correct value of d, but garbage in c.

Could we perhaps at -O0 avoid allocating user variables that are live accross
function calls in call-clobbered registers?  For -O1 it is obviously a fine
decision.


-- 
   Summary: [4.4 Regression] gdb.base/store.exp failures
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

[Bug target/39431] [4.3/4.4 regression ICE in spill_failure, at reload1.c:2093

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2009-03-11 14:09 ---
tested 4.3.4 SVN 20090301 and 4.4.0 SVN 20090225.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[chrbr at gcc dot gnu dot org]

--- Comment #8 from chrbr at gcc dot gnu dot org  2009-03-11 14:07 ---
I have picky disabled the canonicalization in fold_plusminus_mult_expr for 
identical constants that are power of 2, so my mov @(disp, rn) is back :-(. For
some reason your patch let the base+index computation factorization thru 

This is experimental for now, because expand_expr needs to be extended to
repair expressions like return ((a * 4) + 4) that are not an indirect_ref.
(thanks we differ PLUS expr from POINTER_PLUS_EXPR)

+++ fold-const.c2009-03-11 13:49:40.0 +0100
@@ -7431,7 +7431,10 @@
   same = NULL_TREE;

   if (operand_equal_p (arg01, arg11, 0))
-same = arg01, alt0 = arg00, alt1 = arg10;
+{
+  if (code != PLUS_EXPR || exact_log2 (TREE_INT_CST_LOW (arg01)) == -1)
+   same = arg01, alt0 = arg00, alt1 = arg10;
+}
   else if (operand_equal_p (arg00, arg10, 0))
 same = arg00, alt0 = arg01, alt1 = arg11;
   else if (operand_equal_p (arg00, arg11, 0))


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug target/39431] [4.3/4.4 regression ICE in spill_failure, at reload1.c:2093

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2009-03-11 14:07 ---
Created an attachment (id=17437)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17437&action=view)
preprocessed source


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug target/39431] New: [4.3/4.4 regression ICE in spill_failure, at reload1.c:2093

[doko at ubuntu dot com]

seen when building the OpenJDK Zero port on ix86:

works when using -march=i486 instead of -march=i585.

$ g++-4.2 -c -march=i586 -g -O3 -fPIC -c jvm.ii
$ g++-4.3 -c -march=i586 -g -O3 -fPIC -c jvm.ii 
/scratch/packages/openjdk/u/openjdk-6-6b14-1.4.1/build-zero/openjdk/hotspot/src/share/vm/prims/jvm.cpp:
In function 'jboolean JVM_CX8Field(JNIEnv*, _jobject*, _jfieldID*, jlong,
jlong)':
/scratch/packages/openjdk/u/openjdk-6-6b14-1.4.1/build-zero/openjdk/hotspot/src/share/vm/prims/jvm.cpp:4206:
error: unable to find a register to spill in class 'GENERAL_REGS'
/scratch/packages/openjdk/u/openjdk-6-6b14-1.4.1/build-zero/openjdk/hotspot/src/share/vm/prims/jvm.cpp:4206:
error: this is the insn:
(insn:HI 71 68 72 11
/scratch/packages/openjdk/u/openjdk-6-6b14-1.4.1/build-zero/openjdk/hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp:295
(parallel [
(set (reg:DI 65 [ D.129908 ])
(mem/v:DI (plus:SI (reg/f:SI 58 [ prephitmp.14780 ])
(reg/v/f:SI 71 [ fid ])) [-1 S8 A64]))
(set (mem/v:DI (plus:SI (reg/f:SI 58 [ prephitmp.14780 ])
(reg/v/f:SI 71 [ fid ])) [-1 S8 A64])
(unspec_volatile:DI [
(mem/v:DI (plus:SI (reg/f:SI 58 [ prephitmp.14780 ])
(reg/v/f:SI 71 [ fid ])) [-1 S8 A64])
(reg/v:DI 72 [ oldVal ])
(reg:SI 101 [ newVal ])
(reg:SI 102 [ newVal+4 ])
] 10))
(clobber (reg:CC 17 flags))
]) 1507 {*sync_double_compare_and_swapdi_pic} (expr_list:REG_DEAD
(reg:SI 102 [ newVal+4 ])
(expr_list:REG_DEAD (reg:SI 101 [ newVal ])
(expr_list:REG_DEAD (reg/v/f:SI 71 [ fid ])
(expr_list:REG_DEAD (reg/f:SI 58 [ prephitmp.14780 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))


-- 
   Summary: [4.3/4.4 regression ICE in spill_failure, at
reload1.c:2093
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
  GCC host triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431

[Bug target/36834] structure return ABI for windows targets differs from native MSVC

[mattias at virtutech dot se]

--- Comment #5 from mattias at virtutech dot se  2009-03-11 12:42 ---
(In reply to comment #4)

>http://209.85.173.132/search?q=cache:e7XCjhLwHacJ:luabinaries.luaforge.net/manual.html+http://luabinaries.luaforge.net/manual.html%23LuaBinariesCompatible&hl=en&ct=clnk&cd=1&gl=us&client=opera
> is it the same bug [they mention incompats when passing CRT objects among
> libraries]? dunno.

No, that page is concerned with multiple CRTs in the same process and passing
around values between them (such as using fopen() in one CRT and fclose() in
another).

This bug is about calling conventions for functions returning structs by value.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834

[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2009-03-11 12:30 ---
*** Bug 39430 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||algrant at acm dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38615

[Bug c/39430] GCC does not put 'const auto' structure on the stack

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-03-11 12:30 ---


*** This bug has been marked as a duplicate of 38615 ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39430

[Bug c/39430] New: GCC does not put 'const auto' structure on the stack

[algrant at acm dot org]

This code creates an 'activation record' structure for each active
call to the function:

  struct frame { char const *name; int line; };
  extern void trace(struct frame const *);
  int f(int n) {
const struct frame v = { __FUNCTION__, __LINE__ };
trace(&v);
return n ? n*f(n-1) : 1;
  }

These should be distinct, i.e. their addresses are distinct to
any observer.  But GCC evaluates &v to refer to one instance in
static storage.  Surely the standard doesn't allow an implementation
to do this.  It doesn't happen if 'v' is not marked 'const'.


-- 
   Summary: GCC does not put 'const auto' structure on the stack
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39430

[Bug target/36834] structure return ABI for windows targets differs from native MSVC

[rogerpack2005 at gmail dot com]

--- Comment #4 from rogerpack2005 at gmail dot com  2009-03-11 11:35 ---
I'd be willing to offer a small bounty for this one.  Maybe $50 for an accepted
patch that handles both the caller and callee sides?

The problem seems to be common [1].

Thanks!
-=r
[1]
http://209.85.173.132/search?q=cache:e7XCjhLwHacJ:luabinaries.luaforge.net/manual.html+http://luabinaries.luaforge.net/manual.html%23LuaBinariesCompatible&hl=en&ct=clnk&cd=1&gl=us&client=opera
is it the same bug [they mention incompats when passing CRT objects among
libraries]? dunno.


-- 

rogerpack2005 at gmail dot com changed:

   What|Removed |Added

 CC||rogerpack2005 at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834

[Bug rtl-optimization/39428] Stack allocation in the assembly output is more than needed.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-11 10:54 ---
The stack is aligned this way by default.  You can use
-mpreferred-stack-boundary=2 to shrink it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39428

[Bug c++/39425] [4.2/4.3/4.4 Regression] gcc loops after reporting template instantiation errors

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-11 10:48 ---
Confirmed.  4.1 does

g++-4.1 -S t.ii -ftemplate-depth-4
t.ii:8: error: explicit specialization in non-namespace scope ‘class a’
t.ii:15: error: expected unqualified-id at end of input


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.2.4 4.3.3 4.4.0
  Known to work||4.1.2
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 10:48:39
   date||
Summary|gcc loops after reporting   |[4.2/4.3/4.4 Regression] gcc
   |template instantiation  |loops after reporting
   |errors  |template instantiation
   ||errors
   Target Milestone|--- |4.2.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39425

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-03-11 10:25 
---
> I thought that the now what as with your patch. So it looks indeed like quite
> similar to what I see. I'll try to see why it doesn't solve my case.

Reverting to the old canonicalization at the tree level is not doable, that's
why the patch does it during RTL expansion and only for offsets.  It probably
would need to be extended if that's not sufficient for your testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[chrbr at gcc dot gnu dot org]

--- Comment #6 from chrbr at gcc dot gnu dot org  2009-03-11 09:46 ---
(In reply to comment #5)
> > Thanks, I tried your patch against a 4.3.3 base but it didn't fix the 
> > problem,
> > your patch canonicalizes while what I need is a distribution
> 
> Read again the RTL expander hunk.
> 

ah yes sorry, when I read
"
  base + 2*ind - 2

now it's

  base + (1-ind) * -2
"
I thought that the now what as with your patch. So it looks indeed like quite
similar to what I see. I'll try to see why it doesn't solve my case.

thanks,


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-03-11 09:36 
---
> Thanks, I tried your patch against a 4.3.3 base but it didn't fix the problem,
> your patch canonicalizes while what I need is a distribution

Read again the RTL expander hunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug testsuite/39422] [4.4 regression] Failing SPU vectorizer testcases

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2009-03-11 09:34 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39422

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[chrbr at gcc dot gnu dot org]

--- Comment #4 from chrbr at gcc dot gnu dot org  2009-03-11 09:30 ---
(In reply to comment #3)
> See http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01134.html
> 

Thanks, I tried your patch against a 4.3.3 base but it didn't fix the problem,
your patch canonicalizes while what I need is a distribution
(base + 1) * 4 => base * 4 + 4


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-03-11 09:06 
---
See http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01134.html


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[chrbr at gcc dot gnu dot org]

-- 

chrbr at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |chrbr at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-03-11 08:52:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug target/39423] [SH] performance regression: lost mov @(disp,Rn)

[chrbr at gcc dot gnu dot org]

--- Comment #2 from chrbr at gcc dot gnu dot org  2009-03-11 08:46 ---
I observed some large performance regressions in 4.3 and upwards for many
benchmarks for the superh targets, There are many causes but the main one is
reduced to the indirect+offset access :

int
foo (int tab[], int index)
{
  return tab [index+1];
} 

compiles (-O2 -fomit-frame-pointer) into 
mov r5,r0
add #1,r0
shll2   r0
rts 
mov.l   @(r0,r4),r0

instead of
shll2   r5
add r4,r5
rts 
mov.l   @(4,r5),r0

Note that in more complex code the problem is emphasized because only r0
register class can be used as indirect register index, putting extra pressure
on reload.

It seems to be that the problem is in the way that the constant index is now
hidden by gimple, so we now have

 return *(tab + ((unsigned int) index + 1) * 4)

instead of 

 return *(tab + 4B + (int *) ((unsigned int) index * 4))

It seems more easy to change gimple, but this is a target dependant
transformation. On the other hand the RTL code gen should be able to
redistribute the factorization, but that seems extra work to undo what was done
previously.


-- 

chrbr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
Summary|[   |[SH]  performance
   ||regression: lost mov
   ||@(disp,Rn)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

[Bug c++/39429] New: compiler create bad asm codes.

[ryos at sinby dot com]

the Compiler creates bad asm codes from following source.

bool
ArmGccTest::useOffScreen()
{
if ((mapsize - size) < 16*1024)
return false;

return true;
}


.text
.align  2
.global _ZN10ArmGccTest12useOffScreenEv
.type   _ZN10ArmGccTest12useOffScreenEv, %function
_ZN10ArmGccTest12useOffScreenEv:
.fnstart
.LFB2:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r0, [r0, #1080]
ldr r3, [r0, #1084]
sub r0, r0, r3
cmp r0, #16384
movcc   r0, #0
movcs   r0, #1
bx  lr

r0 is assigned for "this". however r0 is rewritten to use "mapsize", so r3 is
broken.  You can see this problem by following simple c++ source.

class ArmGccTest {
private:
unsigned int value001;




unsigned int value109;
unsigned int value10a;
unsigned int value10b;
unsigned int value10c;
unsigned int value10d;

unsigned int mapsize;
unsigned int size;

unsigned int value10e;

bool useOffScreen();
};


-- 
   Summary: compiler create bad asm codes.
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ryos at sinby dot com
  GCC host triplet: arm-linux, i386-linux, i386-freebsd
GCC target triplet: arm-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429