GNU profiling - profil()
HI, I have a question related to profiling. In glibc, the function definition of profil() is existing in the following places glibc-2.4/gmon/profil.c glibc-2.4/sysdeps/mach/hurd/profil.c glibc-2.4/sysdeps/posix/profil.c glibc-2.4/unix/sysv/linux/profil.c If we compile the source code with gcc -pg option, which profil() function among the above will be executed in i386 ? I want to confirm is it from glibc-2.4/sysdeps/posix/profil.c ? Thanks and Regards Raja Saleru
(.eh_frame); no .eh_frame_hdr table will be created
Hello! I'm having an application that is build on FC3 and works fine on FC releases starting from 3d to 8th. I also have no troubles with RHEL starting from 4 to 5 (including updates). But when I'm trying to launch my application on FC9 I'm getting a sigfault. I tried to rebuild my application on FC9 with gcc4.3 but it crashes again with the following backtrace: - #0 0x0223ec45 in ?? () #1 0x0023c8c5 in ?? () from /usr/lib/libstdc++.so.6 #2 0x085a2b23 in __dynamic_cast (from=0x23c8c0, to=0x238298 typeinfo for std::locale::facet, require_public=2326848, address=0x0, sub=0x1c2379 bool std::has_facetstd::ctypechar (std::locale const)+9, subptr=0x23aff4) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #3 0x001c23ca in std::has_facetstd::ctypechar () from /usr/lib/libstdc++.so.6 #4 0x001b64e8 in std::basic_ioschar, std::char_traitschar ::_M_cache_locale () from /usr/lib/libstdc++.so.6 #5 0x001b6597 in std::basic_ioschar, std::char_traitschar ::init () from /usr/lib/libstdc++.so.6 #6 0x001a0d36 in std::ios_base::Init::Init () from /usr/lib/libstdc++.so.6 #7 0x082d9794 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:77 #8 0x082d97cd in global constructors keyed to main () at /home/user/main.cc:334 #9 0x0875d71d in __do_global_ctors_aux () #10 0x081169a4 in _init () #11 0x0875d619 in __libc_csu_init () #12 0x00429571 in __libc_start_main (main=0x82d9816 main, argc=1, ubp_av=0xbfdb2ab4, init=0x875d600 __libc_csu_init, fini=0x875d5f0 __libc_csu_fini, rtld_fini=0x11edd0 _dl_fini, stack_end=0xbfdb2aac) at libc-start.c:179 #13 0x08119d11 in _start () - Actually, I've never met something similar on any FC release and on gcc releases 3.4 - 4.2. I do linkage of my application with libstdc++ library taken from gcc2.95, but linker gives me the following errors: - /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opdel.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opnew.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opvdel.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opvnew.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(exception.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libstdc++.a(fstream.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libstdc++.a(strstream.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libstdc++.a(filebuf.o)(.eh_frame); no .eh_frame_hdr table will be created. - and I assume that these errors cause sigfault. But I've never seen such errors while linking with gcc 3.2, 3.4 or 4.1. Can somebody tell me what have changed in gcc4.3 comparing with previous releases that may lead to the following errors? Thanks! -- View this message in context: http://www.nabble.com/%28.eh_frame%29--no-.eh_frame_hdr-table-will-be-created-tp17594664p17594664.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c/36416] New: internal compiler error: in simplify_subreg_concatn, at lower-subreg.c:398
Trying to build arm-cross for big-endian arm.
Prior to me discovering how to pass the requisit -mbig-endian flag into the
newlib build, it was compiling without hitting the assertion. Now that I am
passing in flags, it chokes. I need the big-endian flags for newlib build, as
well as others.
Originally, I invoked it as:
(cd /home/dap/toolchain/build/newlib\
export PATH=$PATH:/home/dap/tools/bin \
make CFLAGS_FOR_TARGET=-mbig-endian -mfloat-abi=soft
-mabi=aapcs-linux -mcpu=iwmmxt -mwords-little-endian
ASFLAGS_FOR_TARGET=-mfloat-abi=soft -mcpu=iwmmxt+iwmmxt2
CPPFLAGS_FOR_TARGET= CXXFLAGS_FOR_TARGET=-mbig-endian -mfloat-abi=soft
-mabi=aapcs-linux -mcpu=iwmmxt -mwords-little-endian LDFLAGS_FOR_TARGET= all
install)
After the config step of:
(cd ${TOP}/build/newlib \
export PATH=$$PATH:${PREFIX}/bin \
${NEWLIB_SRC}/configure \
--target=arm-linux-elf \
--prefix=${PREFIX})
-*- mode: compilation; default-directory: ~/toolchain/ -*-
Compilation started at Mon Jun 2 15:01:14
~/tools/bin/arm-linux-elf-gcc -v -save-temps
-B/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/ -isystem
/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/targ-include -isystem
/home/dap/toolchain/newlib-1.16.0/newlib/libc/include
-B/home/dap/toolchain/build/newlib/arm-linux-elf/libgloss/arm
-L/home/dap/toolchain/build/newlib/arm-linux-elf/libgloss/libnosys
-L/home/dap/toolchain/newlib-1.16.0/libgloss/arm -DPACKAGE_NAME=\newlib\
-DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\1.16.0\
-DPACKAGE_STRING=\newlib\ 1.16.0\ -DPACKAGE_BUGREPORT=\\ -I.
-I/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib -O2 -DARM_RDI_MONITOR
-fno-builtin -mbig-endian -mfloat-abi=soft -mabi=aapcs-linux -mcpu=iwmmxt
-mwords-little-endian -c -o lib_a-rand.o `test -f 'rand.c' || echo
'/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib/'`rand.c
Using built-in specs.
Target: arm-linux-elf
Configured with: /home/dap/toolchain/gcc-4.3.0/configure -v
--target=arm-linux-elf --prefix=/home/dap/tools --enable-languages=c,c++
--with-libs=yes --enable-examples --with-newlib
--with-headers=/home/dap/toolchain/newlib-1.16.0/newlib/libc/include
Thread model: single
gcc version 4.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps'
'-B/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/' '-isystem'
'/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/targ-include' '-isystem'
'/home/dap/toolchain/newlib-1.16.0/newlib/libc/include'
'-B/home/dap/toolchain/build/newlib/arm-linux-elf/libgloss/arm'
'-L/home/dap/toolchain/build/newlib/arm-linux-elf/libgloss/libnosys'
'-L/home/dap/toolchain/newlib-1.16.0/libgloss/arm' '-DPACKAGE_NAME=newlib'
'-DPACKAGE_TARNAME=newlib' '-DPACKAGE_VERSION=1.16.0'
'-DPACKAGE_STRING=newlib 1.16.0' '-DPACKAGE_BUGREPORT=' '-I.'
'-I/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib' '-O2'
'-DARM_RDI_MONITOR' '-fno-builtin' '-mbig-endian' '-mfloat-abi=soft'
'-mabi=aapcs-linux' '-mcpu=iwmmxt' '-mwords-little-endian' '-c' '-o'
'lib_a-rand.o'
/home/dap/tools/libexec/gcc/arm-linux-elf/4.3.0/cc1 -E -quiet -v -I.
-I/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib -D__USES_INITFINI__
-DPACKAGE_NAME=newlib -DPACKAGE_TARNAME=newlib -DPACKAGE_VERSION=1.16.0
-DPACKAGE_STRING=newlib 1.16.0 -DPACKAGE_BUGREPORT= -DARM_RDI_MONITOR
-isystem /home/dap/toolchain/build/newlib/arm-linux-elf/newlib/targ-include
-isystem /home/dap/toolchain/newlib-1.16.0/newlib/libc/include
/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib/rand.c -mbig-endian
-mfloat-abi=soft -mabi=aapcs-linux -mcpu=iwmmxt -mwords-little-endian
-fno-builtin -O2 -fpch-preprocess -o rand.i
#include ... search starts here:
#include ... search starts here:
.
/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib
/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/targ-include
/home/dap/toolchain/newlib-1.16.0/newlib/libc/include
/home/dap/tools/lib/gcc/arm-linux-elf/4.3.0/include
/home/dap/tools/lib/gcc/arm-linux-elf/4.3.0/include-fixed
/home/dap/tools/lib/gcc/arm-linux-elf/4.3.0/../../../../arm-linux-elf/sys-include
/home/dap/tools/lib/gcc/arm-linux-elf/4.3.0/../../../../arm-linux-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps'
'-B/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/' '-isystem'
'/home/dap/toolchain/build/newlib/arm-linux-elf/newlib/targ-include' '-isystem'
'/home/dap/toolchain/newlib-1.16.0/newlib/libc/include'
'-B/home/dap/toolchain/build/newlib/arm-linux-elf/libgloss/arm'
'-L/home/dap/toolchain/build/newlib/arm-linux-elf/libgloss/libnosys'
'-L/home/dap/toolchain/newlib-1.16.0/libgloss/arm' '-DPACKAGE_NAME=newlib'
'-DPACKAGE_TARNAME=newlib' '-DPACKAGE_VERSION=1.16.0'
'-DPACKAGE_STRING=newlib 1.16.0' '-DPACKAGE_BUGREPORT=' '-I.'
'-I/home/dap/toolchain/newlib-1.16.0/newlib/libc/stdlib' '-O2'
'-DARM_RDI_MONITOR' '-fno-builtin' '-mbig-endian' '-mfloat-abi=soft'
[Bug driver/36417] New: On Vista, driver can't find collect2
On a i586-pc-mingw32 system running Windows Vista, it seems that the driver has a hard time finding collect2. This was reported by mail (see http://groups.google.com/group/gnu-fortran/browse_thread/thread/f04805a9af7f57bb). C:\rblos\mrppgfortran mrpp.f -v -o a.exe Driving: gfortran mrpp.f -v -o a.exe -lgfortranbegin -lgfortran Using built-in specs. Target: i586-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared Thread model: win32 gcc version 4.4.0 20080514 (experimental) [trunk revision 135286] (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'a.exe' '-mtune=pentium' c:/program files/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.4.0/ f951.exe mrpp.f -ffixed-form -quiet -dumpbase mrpp.f -mtune=pentium -auxbase mrpp -version -fintrinsic-modules-path c:/program files/gfortran/bin/../lib/ gcc/i586-pc-mingw32/4.4.0/finclude -o C:\Users\myname\AppData\Local\Temp/ccbHfrg3.s GNU Fortran (GCC) version 4.4.0 20080514 (experimental) [trunk revision 135286] (i586-pc-mingw32) compiled by GNU C version 4.4.0 20080514 (experimental) [trunk revision 135286], GMP version 4.2.1, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-v' '-o' 'a.exe' '-mtune=pentium' as -v -o C:\Users\myname\AppData\Local\Temp/ccxWsi98.o C:\Users\myname\AppData\Local\Temp/ccbHfrg3.s GNU assembler version 2.17.50 (mingw32) using BFD version 2.17.50 20060824 COMPILER_PATH= c:/program files/gfortran/bin/../libexec/gcc/i586-pc- mingw32/4.4.0/; c:/program files/gfortran/bin/../libexec/gcc/ LIBRARY_PATH= c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/; c:/program files/gfortran/bin/../lib/gcc/; c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/../../../ COLLECT_GCC_OPTIONS='-v' '-o' 'a.exe' '-mtune=pentium' c:/program files/gfortran/bin/../libexec/gcc/i586-pc- mingw32/4.4.0/collect2.exe -Bdynamic -o a.exe c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/../../../crt2.o c:/program files/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.4.0/ crtbegin.o -Lc:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0 -Lc:/program files/gfortran/bin/../lib/gcc -Lc:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/../../.. C:\Users\myname\AppData\Local\Temp/ccxWsi98.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -l moldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 - lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/crtend.o collect2: CreateProcess: No such file or directory ~~ (some irrelevant stuff deleted from:) C:\rblos\mrppset APPDATA=C:\Users\myname\AppData\Roaming HOMEDRIVE=C: HOMEPATH=\Users\myname INCLUDE= C:\Program Files\Microsoft.NET\FrameworkSDK\include\; C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\; C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Include lib= C:\Program Files\Microsoft Visual Studio .NET\Vc7\lib\; C:\Program Files\Microsoft.NET\FrameworkSDK\Lib\; C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Lib Path= C:\Windows\system32; C:\Windows; C:\Windows\System32\Wbem; C:\Program Files\QuickTime\QTSystem\; C:\Program Files\util; C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Bin; C:\Program Files\gfortran\bin; C:\Program Files\gfortran\libexec\gcc\i586-pc-mingw32\4.4.0 (I verified existance of all paths and files referenced in gfortran - v:) (...except those referenced in Configured with as \mingw\... ) (...I don't have a \mingw installation, as the mingw distro is too old) C:\rblos\mrppcd c:/program files/gfortran/bin/../libexec/gcc/i586-pc- mingw32/4.4.0/ c:\Program Files\gfortran\libexec\gcc\i586-pc-mingw32\4.4.0cd c:/ program files/gfortran/bin/../libexec/gcc c:\Program Files\gfortran\libexec\gcccd c:/program files/gfortran/ bin/../lib/gcc/i586-pc-mingw32/4.4.0/ c:\Program Files\gfortran\lib\gcc\i586-pc-mingw32\4.4.0cd c:/program files/gfortran/bin/../lib/gcc/ c:\Program Files\gfortran\lib\gcccd c:/program files/gfortran/bin/../ lib/gcc/i586-pc-mingw32/4.4.0/../../../ c:\Program Files\gfortran\libcd c:/program files/gfortran/bin/../ libexec/gcc/i586-pc-mingw32/4.4.0/ c:\Program Files\gfortran\libexec\gcc\i586-pc-mingw32\4.4.0dir collect2.exe Volume in drive C has no label. Volume Serial Number is E8AD-DCE7 Directory
[Bug driver/36418] New: On Vista, driver can't find collect2
On a i586-pc-mingw32 system running Windows Vista, it seems that the driver has a hard time finding collect2. This was reported by mail (see http://groups.google.com/group/gnu-fortran/browse_thread/thread/f04805a9af7f57bb). C:\rblos\mrppgfortran mrpp.f -v -o a.exe Driving: gfortran mrpp.f -v -o a.exe -lgfortranbegin -lgfortran Using built-in specs. Target: i586-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared Thread model: win32 gcc version 4.4.0 20080514 (experimental) [trunk revision 135286] (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'a.exe' '-mtune=pentium' c:/program files/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.4.0/ f951.exe mrpp.f -ffixed-form -quiet -dumpbase mrpp.f -mtune=pentium -auxbase mrpp -version -fintrinsic-modules-path c:/program files/gfortran/bin/../lib/ gcc/i586-pc-mingw32/4.4.0/finclude -o C:\Users\myname\AppData\Local\Temp/ccbHfrg3.s GNU Fortran (GCC) version 4.4.0 20080514 (experimental) [trunk revision 135286] (i586-pc-mingw32) compiled by GNU C version 4.4.0 20080514 (experimental) [trunk revision 135286], GMP version 4.2.1, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-v' '-o' 'a.exe' '-mtune=pentium' as -v -o C:\Users\myname\AppData\Local\Temp/ccxWsi98.o C:\Users\myname\AppData\Local\Temp/ccbHfrg3.s GNU assembler version 2.17.50 (mingw32) using BFD version 2.17.50 20060824 COMPILER_PATH= c:/program files/gfortran/bin/../libexec/gcc/i586-pc- mingw32/4.4.0/; c:/program files/gfortran/bin/../libexec/gcc/ LIBRARY_PATH= c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/; c:/program files/gfortran/bin/../lib/gcc/; c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/../../../ COLLECT_GCC_OPTIONS='-v' '-o' 'a.exe' '-mtune=pentium' c:/program files/gfortran/bin/../libexec/gcc/i586-pc- mingw32/4.4.0/collect2.exe -Bdynamic -o a.exe c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/../../../crt2.o c:/program files/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.4.0/ crtbegin.o -Lc:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0 -Lc:/program files/gfortran/bin/../lib/gcc -Lc:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/../../.. C:\Users\myname\AppData\Local\Temp/ccxWsi98.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -l moldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 - lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/program files/gfortran/bin/../lib/gcc/i586-pc- mingw32/4.4.0/crtend.o collect2: CreateProcess: No such file or directory ~~ (some irrelevant stuff deleted from:) C:\rblos\mrppset APPDATA=C:\Users\myname\AppData\Roaming HOMEDRIVE=C: HOMEPATH=\Users\myname INCLUDE= C:\Program Files\Microsoft.NET\FrameworkSDK\include\; C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\; C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Include lib= C:\Program Files\Microsoft Visual Studio .NET\Vc7\lib\; C:\Program Files\Microsoft.NET\FrameworkSDK\Lib\; C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Lib Path= C:\Windows\system32; C:\Windows; C:\Windows\System32\Wbem; C:\Program Files\QuickTime\QTSystem\; C:\Program Files\util; C:\Program Files\Lahey-Fujitsu Fortran\v7.1\Win32\Bin; C:\Program Files\gfortran\bin; C:\Program Files\gfortran\libexec\gcc\i586-pc-mingw32\4.4.0 (I verified existance of all paths and files referenced in gfortran - v:) (...except those referenced in Configured with as \mingw\... ) (...I don't have a \mingw installation, as the mingw distro is too old) C:\rblos\mrppcd c:/program files/gfortran/bin/../libexec/gcc/i586-pc- mingw32/4.4.0/ c:\Program Files\gfortran\libexec\gcc\i586-pc-mingw32\4.4.0cd c:/ program files/gfortran/bin/../libexec/gcc c:\Program Files\gfortran\libexec\gcccd c:/program files/gfortran/ bin/../lib/gcc/i586-pc-mingw32/4.4.0/ c:\Program Files\gfortran\lib\gcc\i586-pc-mingw32\4.4.0cd c:/program files/gfortran/bin/../lib/gcc/ c:\Program Files\gfortran\lib\gcccd c:/program files/gfortran/bin/../ lib/gcc/i586-pc-mingw32/4.4.0/../../../ c:\Program Files\gfortran\libcd c:/program files/gfortran/bin/../ libexec/gcc/i586-pc-mingw32/4.4.0/ c:\Program Files\gfortran\libexec\gcc\i586-pc-mingw32\4.4.0dir collect2.exe Volume in drive C has no label. Volume Serial Number is E8AD-DCE7 Directory
[Bug driver/36417] On Vista, driver can't find collect2
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-06-02 07:49 --- *** Bug 36418 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36417
[Bug driver/36418] On Vista, driver can't find collect2
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-06-02 07:49 --- *** This bug has been marked as a duplicate of 36417 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36418
[Bug tree-optimization/36401] [4.4 Regression] 164.gzip miscompares
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-02 08:56 --- It's working again, and a check with/without the patch produces exactly the same code. So I guess the tester absorbed some HEP. -- 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=36401
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-06-02 11:29 --- It's a front-end issue: as the BOUNDARY character argument is not present, its length is not appended to the argument list as it should. I guess we need to add a gfc_conv_intrinsic_eoshift function in trans-intrinsic.c to take care of EOSHIFT. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-02 11:29:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug c++/36404] [4.2/4.3/4.4 regression] ICE with invalid enum
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-02 11:40 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-02 11:40:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36404
[Bug middle-end/36414] g++ causes segmentation violation on template test program
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-02 08:50 --- Fixed in 4.0.0 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Known to fail||3.4.6 Known to work||4.0.0 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36414
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #42 from rguenth at gcc dot gnu dot org 2008-06-02 11:48 --- Can we please do something about this? Either make -fno-exceptions unconditionally always only execute the try block via frontend support (and not only if you happen to include some libstdc++ header), or apply the suggested fix of only fixing up the standard library and let user programs still using exceptions when they specify -fno-exceptions error during compilation. Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|blocker Keywords||accepts-invalid, wrong-code Known to fail|4.1.3 |4.1.3 4.3.0 Last reconfirmed|2007-03-22 10:46:19 |2008-06-02 11:48:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- Comment #10 from burnus at gcc dot gnu dot org 2008-06-02 08:44 --- Should I add another test case with an assumed shape array (or simply change proc_decl_12.f90 to have an assumed shape instead of an explicit shape array)? Or is proc_decl_12.f90 enough as it is? In principle, no test case should be removed - only new ones added. (I try to find time this evening to look at the PRs and at your patch, http://gcc.gnu.org/ml/fortran/2008-06/msg1.html ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #43 from paolo dot carlini at oracle dot com 2008-06-02 12:05 --- Ok, I will just implement the __try / __catch suggestion. Hopefully the other library maintainers will not disagree... -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug rtl-optimization/36419] New: [4.3 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
The following testcase gets wrong unwind info with -m32 -Os -fpic -fno-asynchronous-unwind-tables on the 4.3 branch (haven't tried 4.4 yet). The problem is incorrect DW_CFA_GNU_args_size (usually off by 16), which results in catch receiving %esp 16 bytes above what should be received. As this catch is called in the loop 10 times, each iteration bumps %esp by 16 bytes and eventually trashes saved variables on the stack (in http://bugzilla.redhat.com/447912 case already the 3rd iteration overwrites saved stderr pointer on the stack). The interesting function is _ZN17OleEmbeddedObject44TryToRetrieveCachedVisualRepresentation_ImplERKN3com3sun4star3uno9ReferenceINS2_2io7XStreamEEEh. From what I can see, DW_CFA_GNU_args_size matches the code from the beginning until first call [EMAIL PROTECTED] After the following addl $16, %esp it is still right (after that insns args_size is set to 0): .LCFI2090: call[EMAIL PROTECTED] addl$16, %esp .LCFI2091: jmp .L542 ... .long .LCFI2090-.LCFI2089 .byte 0x2e# DW_CFA_GNU_args_size .uleb128 0x10 .byte 0x4 # DW_CFA_advance_loc4 .long .LCFI2091-.LCFI2090 .byte 0x2e# DW_CFA_GNU_args_size .uleb128 0x0 But the code jmp .L542 jumps to has args_size 16, not 0: .LCFI2098: call[EMAIL PROTECTED] addl$16, %esp .LCFI2099: .LEHB94: call[EMAIL PROTECTED] .LEHE94: .L542: # basic block 17 cmpl$0, -20(%ebp) je .L547 # basic block 18 movl[EMAIL PROTECTED](%ebx), %edx movl$0, -144(%ebp) movl%edx, -168(%ebp) movl%edx, -172(%ebp) movl%edx, -176(%ebp) .L565: # basic block 19 pushl %eax .LCFI2100: ... .long .LCFI2098-.LCFI2097 .byte 0x2e# DW_CFA_GNU_args_size .uleb128 0x20 .byte 0x4 # DW_CFA_advance_loc4 .long .LCFI2099-.LCFI2098 .byte 0x2e# DW_CFA_GNU_args_size .uleb128 0x10 .byte 0x4 # DW_CFA_advance_loc4 .long .LCFI2100-.LCFI2099 .byte 0x2e# DW_CFA_GNU_args_size .uleb128 0x14 Without -fasynchronous-unwind-tables it honors second operands of CALL rtls and those are correct for this codepath. -- Summary: [4.3 Regression] Wrong unwind info with -Os - fasynchronous-unwind-tables Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug rtl-optimization/36419] [4.3 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-02 13:49 --- Created an attachment (id=15712) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15712action=view) rh447912.ii.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug fortran/36420] New: Fortran 2008: g0 edit descriptor
Fortran 2008 supports besides G[w.d[Ee]] (with w 0) now also G0 (without .d[Ee]). The G0 edit descriptor is to a certain extend equivalent to * for a single argument. G0 is thus: - (integer) i0 - (character) a - (logical) l1 - (real/complex) When used to specify the output of real or complex data, the G0 edit descriptor follows the rules for the ESw.dEe edit descriptor. Reasonable processor-dependent values of w, d, and e are used with each output value. -- Summary: Fortran 2008: g0 edit descriptor Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug rtl-optimization/36419] [4.3 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-02 14:08 --- Important correction, it works with: -m32 -Os -fpic -fno-asynchronous-unwind-tables but doesn't with: -m32 -Os -fpic -fasynchronous-unwind-tables which generates identical .text, but different unwind info. The code in between that jmp .L542 and .L542: looks broken: .LCFI2090: call[EMAIL PROTECTED] addl$16, %esp .LCFI2091: jmp .L542 .L543: .L621: # basic block 13 .L544: movl%eax, %edi subl$12, %esp .LCFI2092: leal-32(%ebp), %eax movl%edx, %esi pushl %eax .LCFI2093: call[EMAIL PROTECTED] jmp .L545 .LCFI2094: .L622: # basic block 14 movl%eax, %edi movl%edx, %esi .L545: # basic block 15 .L623: subl$12, %esp .LCFI2095: pushl -28(%ebp) .LCFI2096: call[EMAIL PROTECTED] cmpl$1, %esi jne .L592 # basic block 16 .L546: subl$12, %esp .LCFI2097: pushl %edi .LCFI2098: call[EMAIL PROTECTED] addl$16, %esp .LCFI2099: .LEHB94: call[EMAIL PROTECTED] .LEHE94: .L542: # basic block 17 cmpl$0, -20(%ebp) Both .L621 and .L622 are landing pads, so I believe args_size should be 0 at those points (and the dwarf2out code even clears args_size on BARRIERs). call[EMAIL PROTECTED] is done with args_size 16, which looks correct, but it then jumps to .L545 without addl 16, %esp which would be IMNSHO expected to get stack pointer back to args_size 0 level, and .L545 is after barrier with no stack changes. When entering the .L622 landing pad call[EMAIL PROTECTED] is done with correct args_size 16, but the following call [EMAIL PROTECTED] is done with args_size 32, eventhough the call only has one parameter and so should be 16. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug fortran/36421] New: Gw.d edit descriptor for integer numbers: Wrong output
(Cf. PR 36420 for G0.) print '(a,g4.2,a0)', ':',4,':' end should print the same as I4, namely : 4. However, gfortran prints it as : 04, which is the same as I4.2. The standard states [F2003]: 10.6.4.1.1 Generalized integer editing / When used to specify the input/output of integer data, the Gw.d and Gw.d Ee edit descriptors follow the rules for the Iw edit descriptor (10.6.1.1), except that w shall not be zero. -- Summary: Gw.d edit descriptor for integer numbers: Wrong output Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug fortran/36422] New: Misleading error message for (a0) edit descriptor
print '(a0)', ':' 1 Error: Expected P edit descriptor in format string at (1) Expected: Error: Positive width required in format string at (1) -- Summary: Misleading error message for (a0) edit descriptor Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36422
[Bug fortran/36422] Misleading error message for (a0) edit descriptor
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-02 14:16 --- Same for the run-time error message: At line 2 of file aa.f90 (unit = 6, file = 'stdout') Fortran runtime error: Expected P edit descriptor in format -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36422
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-02 14:43 --- Jerry, is this patch inserted at the right place or is there a better place? Where do you think one should modify in order to get g0 working (PR36420 / F2008)? Index: libgfortran/io/write.c === --- libgfortran/io/write.c (Revision 136271) +++ libgfortran/io/write.c (Arbeitskopie) @@ -340,7 +340,11 @@ write_decimal (st_parameter_dt *dtp, con char itoa_buf[GFC_BTOA_BUF_SIZE]; w = f-u.integer.w; - m = f-u.integer.m; + + if (f-format == FMT_G) +m = 0; + else +m = f-u.integer.m; n = extract_int (source, len); -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #11 from burnus at gcc dot gnu dot org 2008-06-02 15:32 --- Another link dump: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4 Some of the test cases should be checked when the proc pointer patch is ready to ensure all are passed. (Forward carrying this link from PR 36322 which is about to be fixed.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
Re: (.eh_frame); no .eh_frame_hdr table will be created
Hello Rusyy! Please use --traditional-format option to linker to suppress warning messages, but I doubt that this will resolve your problem. You, probably, have to play with libraries that you link into your application and check constructors initialization. Regards, Dima Rusyy wrote: Hello! I'm having an application that is build on FC3 and works fine on FC releases starting from 3d to 8th. I also have no troubles with RHEL starting from 4 to 5 (including updates). But when I'm trying to launch my application on FC9 I'm getting a sigfault. I tried to rebuild my application on FC9 with gcc4.3 but it crashes again with the following backtrace: - #0 0x0223ec45 in ?? () #1 0x0023c8c5 in ?? () from /usr/lib/libstdc++.so.6 #2 0x085a2b23 in __dynamic_cast (from=0x23c8c0, to=0x238298 typeinfo for std::locale::facet, require_public=2326848, address=0x0, sub=0x1c2379 bool std::has_facetstd::ctypechar (std::locale const)+9, subptr=0x23aff4) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #3 0x001c23ca in std::has_facetstd::ctypechar () from /usr/lib/libstdc++.so.6 #4 0x001b64e8 in std::basic_ioschar, std::char_traitschar ::_M_cache_locale () from /usr/lib/libstdc++.so.6 #5 0x001b6597 in std::basic_ioschar, std::char_traitschar ::init () from /usr/lib/libstdc++.so.6 #6 0x001a0d36 in std::ios_base::Init::Init () from /usr/lib/libstdc++.so.6 #7 0x082d9794 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:77 #8 0x082d97cd in global constructors keyed to main () at /home/user/main.cc:334 #9 0x0875d71d in __do_global_ctors_aux () #10 0x081169a4 in _init () #11 0x0875d619 in __libc_csu_init () #12 0x00429571 in __libc_start_main (main=0x82d9816 main, argc=1, ubp_av=0xbfdb2ab4, init=0x875d600 __libc_csu_init, fini=0x875d5f0 __libc_csu_fini, rtld_fini=0x11edd0 _dl_fini, stack_end=0xbfdb2aac) at libc-start.c:179 #13 0x08119d11 in _start () - Actually, I've never met something similar on any FC release and on gcc releases 3.4 - 4.2. I do linkage of my application with libstdc++ library taken from gcc2.95, but linker gives me the following errors: - /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opdel.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opnew.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opvdel.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(opvnew.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libgcc.a(exception.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libstdc++.a(fstream.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libstdc++.a(strstream.o)(.eh_frame); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/dima/work/uimx/rcs2/linux/uimxdir/uxgcc/lib/libstdc++.a(filebuf.o)(.eh_frame); no .eh_frame_hdr table will be created. - and I assume that these errors cause sigfault. But I've never seen such errors while linking with gcc 3.2, 3.4 or 4.1. Can somebody tell me what have changed in gcc4.3 comparing with previous releases that may lead to the following errors? Thanks! -- View this message in context: http://www.nabble.com/%28.eh_frame%29--no-.eh_frame_hdr-table-will-be-created-tp17594664p17604807.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug fortran/35031] ELEMENTAL procedure with BIND(C)
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-02 16:06 --- Draft 2003 corrigendum 3: ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1727.pdf (Not yet sent to ISO and thus also not ISO approved.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35031
[Bug fortran/36375] ICE on -fpreprocessed
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-06-02 16:41 --- Subject: Bug 36375 Author: dfranke Date: Mon Jun 2 16:41:08 2008 New Revision: 136283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136283 Log: 2008-06-02 Daniel Franke [EMAIL PROTECTED] PR fortran/36375 PR fortran/36377 * cpp.c (gfc_cpp_init): Do not initialize builtins if processing already preprocessed input. (gfc_cpp_preprocess): Finalize output with newline. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36375
[Bug fortran/36375] ICE on -fpreprocessed
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-06-02 16:43 --- Fixed on trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36375
[Bug fortran/36377] newline missing at end of preprocessed output
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-06-02 16:41 --- Subject: Bug 36377 Author: dfranke Date: Mon Jun 2 16:41:08 2008 New Revision: 136283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136283 Log: 2008-06-02 Daniel Franke [EMAIL PROTECTED] PR fortran/36375 PR fortran/36377 * cpp.c (gfc_cpp_init): Do not initialize builtins if processing already preprocessed input. (gfc_cpp_preprocess): Finalize output with newline. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36377
[Bug middle-end/36184] gimple-tuples-branch fails bootstrap on x86 Darwin
--- Comment #3 from dnovillo at gcc dot gnu dot org 2008-06-02 17:04 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2008-05/msg02061.html. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36184
[Bug fortran/36377] newline missing at end of preprocessed output
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-06-02 16:44 --- Fixed on trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36377
[Bug middle-end/36212] Vector alignment overides Target alignment
-- eric dot weddington at atmel dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36212
[Bug rtl-optimization/36419] [4.3 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-02 17:23 ---
Smaller testcase for -m32 -Os -fpic -fasynchronous-unwind-tables -fno-inline:
extern C
{
struct FILE;
extern FILE *stderr;
extern int fprintf (FILE *, const char *, ...);
struct R { int r1; unsigned short r2[1]; };
int bar1 (unsigned short *, int, short) throw ();
void bar2 (R *) throw ();
void bar3 (R **, const unsigned short *, int) throw ();
void bar4 (R **, const char *) throw ();
void bar5 (R **, R *) throw ();
void bar6 (R **, R *, R *) throw ();
}
struct S
{
R *s;
struct T { };
S (R *x, T *) { s = x; }
~S () { bar2 (s); }
S operator= (const S x);
S operator+= (const S x);
S sfn1 (const S x) const;
friend S operator+ (const S x1, const S x2);
static S sfn2 (int i)
{
unsigned short q[33];
R *p = 0;
bar3 (p, q, bar1 (q, i, 10));
return S (p, (T *) 0);
}
static S sfn3 (const char *x)
{
R *p = 0;
bar4 (p, x);
return S (p, (T *) 0);
}
};
struct U { };
template class C inline unsigned char operator = (const U , C );
struct V;
struct W
{
V *w;
unsigned char is () const;
};
template class T struct X : public W
{
static T *xfn1 (V *p);
inline ~X ();
X ();
X (const W rRef);
T *operator - () const;
};
struct E
{
E ();
E (const S , const X V );
E (E const );
~E ();
E operator = (E const );
S e;
X V f;
};
struct V
{
virtual void release () throw () = 0;
};
template class T X T::~X ()
{
if (w)
w-release ();
}
struct Y
{
virtual U yfn1 (const S aName) = 0;
};
struct Z;
X V baz1 (const S ) throw (E);
X Z baz2 (const X Z xStream) throw (E);
X Z foo () throw ()
{
X Z xResult;
X Y xNameContainer;
try
{
xNameContainer =
X Y
(baz1
(S::sfn3 (com.sun.star.embed.OLESimpleStorage)));
}
catch (E )
{
}
if (xNameContainer.is ())
{
for (int nInd = 0; nInd 10; nInd++)
{
S aStreamName = S::sfn3 (abcd);
aStreamName += S::sfn2 ((int) nInd);
X Z xCachedCopyStream;
try
{
{
fprintf (stderr, trying %d\n, nInd);
}
if ((xNameContainer-
yfn1 (aStreamName) = xCachedCopyStream))
if (xCachedCopyStream.is ())
{
{
fprintf (stderr, still trying %d\n, nInd);
}
xResult = baz2 (xCachedCopyStream);
if (xResult.is ())
break;
}
{
fprintf (stderr, success on %d\n, nInd);
}
}
catch (...)
{
fprintf (stderr, failure on %d\n, nInd);
}
}
}
return xResult;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug target/35788] MIPS stack overflow caused by addui instruction
--- Comment #10 from rsandifo at gcc dot gnu dot org 2008-06-02 17:19 --- No response. Looks like this is invalid. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
[Bug target/36424] New: avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization
Testcase:
#include avr/io.h
#include avr/interrupt.h
volatile unsigned char UART_RxChar;
volatile unsigned char UART_ReceivedChar;
SIGNAL(SIG_USART_RECV)
{
/* Indicate that the UART has received a character */
UART_ReceivedChar = 1;
/* Store received character */
UART_RxChar = UDR;
}
Request: use -frename-registers optimization, enabled on -O3.
Result code:
.global __vector_13
.type __vector_13, @function
__vector_13:
.LFB2:
.LM1:
push __zero_reg__
push r0
in r0,__SREG__
push r0
clr __zero_reg__
push r24
/* prologue: Signal */
/* frame size = 0 */
.LM2:
ldi r26,lo8(1)
sts UART_ReceivedChar,r26
.LM3:
lds r24,198
sts UART_RxChar,r24
/* epilogue start */
.LM4:
pop r24
pop r0
out __SREG__,r0
pop r0
pop __zero_reg__
reti
R26 register used in ISR but don't saved/restored.
To fix bug, need define HARD_REGNO_RENAME_OK macro in config/avr.h
Anatoly.
--
Summary: avr-gcc use don't saved registers in ISR with -O3 ('-
frename-registers' ) optimization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aesok at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36424
[Bug target/36424] avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization
--- Comment #1 from aesok at gcc dot gnu dot org 2008-06-02 18:06 --- Created an attachment (id=15713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15713action=view) The patch for 36424 -- aesok at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aesok at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36424
[Bug target/36423] New: avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization
Testcase:
#include avr/io.h
#include avr/interrupt.h
volatile unsigned char UART_RxChar;
volatile unsigned char UART_ReceivedChar;
SIGNAL(SIG_USART_RECV)
{
/* Indicate that the UART has received a character */
UART_ReceivedChar = 1;
/* Store received character */
UART_RxChar = UDR;
}
Request: use -frename-registers optimization, enabled on -O3.
Result code:
.global __vector_13
.type __vector_13, @function
__vector_13:
.LFB2:
.LM1:
push __zero_reg__
push r0
in r0,__SREG__
push r0
clr __zero_reg__
push r24
/* prologue: Signal */
/* frame size = 0 */
.LM2:
ldi r26,lo8(1)
sts UART_ReceivedChar,r26
.LM3:
lds r24,198
sts UART_RxChar,r24
/* epilogue start */
.LM4:
pop r24
pop r0
out __SREG__,r0
pop r0
pop __zero_reg__
reti
R26 register used in ISR but don't saved/restored.
To fix bug, need define HARD_REGNO_RENAME_OK macro in config/avr.h
Anatoly.
--
Summary: avr-gcc use don't saved registers in ISR with -O3 ('-
frename-registers' ) optimization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aesok at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36423
[Bug target/36425] Option -mno-isel not working
--- Comment #1 from edmar at freescale dot com 2008-06-02 18:22 --- Created an attachment (id=15714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15714action=view) Patch to fix the bug The lines deleted in the patch are executed after the command line is parsed. The variable rs6000_isel is already properly set at linuspe.h and eabispe.h, so no futher action is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug tree-optimization/36389] [tuples] gimplify_cond_expr should be smarter
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-02 18:20 --- Subject: Bug 36389 Author: jakub Date: Mon Jun 2 18:19:29 2008 New Revision: 136287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136287 Log: PR tree-optimization/36389 * gimplify.c (gimplify_cond_expr): If one or both branches are GOTO_EXPRs jumping to LABEL_DECLs, don't create unnecessary extra LABEL_DECLs and jumps around. * tree-cfg.c (remove_useless_stmts_cond): Set may_branch also for GIMPLE_COND stmts. * tree-eh.c (replace_goto_queue_cond_clause): Set label to create_artificial_label () rather than LABEL_EXPR. Modified: branches/gimple-tuples-branch/gcc/ChangeLog.tuples branches/gimple-tuples-branch/gcc/gimplify.c branches/gimple-tuples-branch/gcc/tree-cfg.c branches/gimple-tuples-branch/gcc/tree-eh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36389
[Bug target/36425] New: Option -mno-isel not working
The command line -mno-isel does not disable isel generation on e500v[12]
targets.
Test case is:
int
foo (int x, int y)
{
if (x y)
return x;
else
return y;
Compiled with -O2 -mno-isel
--
Summary: Option -mno-isel not working
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edmar at freescale dot com
GCC host triplet: powerpc-unkown-linux-gnuspe
GCC target triplet: powerpc-unkown-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug target/34932] [avr] ICE in reload
--- Comment #6 from eric dot weddington at atmel dot com 2008-06-02 19:02 --- Fixed in 4.4.0. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34932
[Bug middle-end/36342] [4.4 Regression] Missing file name in compilation diagnostics of preprocessed fortran source
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-06-02 18:55 --- This was reported before the libcpp integration [1]. Probably not a fortran problem at all as it is a warning issued by the middle-end. This did work properly in 4.2 and 4.3. Unassigning myself and moving to middle-end. [1] http://gcc.gnu.org/ml/fortran/2008-05/msg00140.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Component|fortran |middle-end Known to fail||4.4.0 Known to work||4.2.5 4.3.1 Summary|Missing file name in|[4.4 Regression] Missing |compilation diagnostics with|file name in compilation |'-cpp' or '-x f95-cpp-input'|diagnostics of preprocessed ||fortran source http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #16 from oliver dot kellogg at eads dot com 2008-06-02 19:16 --- Created an attachment (id=15715) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15715action=view) output from -fdump-tree-original of gnat1 compiling pkg001u.adb (in reply to comment #15) You can look at the original IL generated, I guess the assignments simply contain millions of element assignments (-fdump-tree-original). Ah, thanks. I believe the code at line 29417 represents the problematic assignment (pkg001u.adb line 296), could somebody check? Some of this stuff looks strange to the layman's eye, for example around line 29402: Unknown tree: loop_stmt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug target/36425] Option -mno-isel not working
--- Comment #2 from joseph at codesourcery dot com 2008-06-02 19:35 --- Subject: Re: Option -mno-isel not working On Mon, 2 Jun 2008, edmar at freescale dot com wrote: The lines deleted in the patch are executed after the command line is parsed. The variable rs6000_isel is already properly set at linuspe.h and eabispe.h, so no futher action is required. There are lots of targets using neither of those headers that support E500 CPUs (every target that uses e500.h), so your patch would stop ISEL being enabled for E500 for those targets. What you want is to set rs6000_isel only if !rs6000_explicit_options.isel. (Or find a mask bit to move out of target_flags so ISEL can be enabled directly from processor_target_table.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug rtl-optimization/36419] [4.3 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-02 20:15 ---
Here is a testcase that can be run, unfortunately during the simplification the
incorrect behavior changed from the stack pointer increasing in each iteration
by 16 bytes into decreasing in each iteration by 4 bytes. That's wrong too of
course.
// { dg-options -Os -fasynchronous-unwind-tables -fpic -fno-inline }
extern C
{
struct FILE;
extern FILE *stderr;
extern int fprintf (FILE *, const char *, ...);
struct R { int r1; unsigned short r2[1]; };
int bar1 (unsigned short *, int, short) throw ();
void bar2 (R *) throw ();
void bar3 (R **, const unsigned short *, int) throw ();
void bar4 (R **, const char *) throw ();
}
struct S
{
R *s;
struct T { };
S (R *x, T *) { s = x; }
~S () { bar2 (s); }
S operator= (const S x);
S operator+= (const S x);
S sfn1 (const S x) const;
friend S operator+ (const S x1, const S x2);
static S sfn2 (int i)
{
unsigned short q[33];
R *p = 0;
bar3 (p, q, bar1 (q, i, 10));
return S (p, (T *) 0);
}
static S sfn3 (const char *x)
{
R *p = 0;
bar4 (p, x);
return S (p, (T *) 0);
}
};
struct U { };
template class C unsigned char operator = (const U , C );
struct V;
struct W
{
V *w;
unsigned char is () const;
};
template class T struct X : public W
{
inline ~X ();
X ();
X (const W );
T *operator - () const;
};
struct E
{
E ();
E (const S , const X V );
E (E const );
~E ();
E operator = (E const );
};
struct V
{
virtual void release () throw ();
};
template class T X T::~X ()
{
if (w)
w-release ();
}
struct Y
{
virtual U yfn1 (const S );
};
struct Z;
X V baz1 (const S ) throw (E);
X Z baz2 (const X Z ) throw (E);
template typename T XT::X ()
{
w = __null;
}
template typename T XT::X (W const )
{
w = __null;
}
U Y::yfn1 (const S )
{
throw 12;
}
Y y;
template typename T T *XT::operator - () const
{
return y;
}
X V baz1 (const S ) throw (E)
{
return XV ();
}
E::E ()
{
}
E::~E ()
{
}
X Z baz2 (const X Z ) throw (E)
{
throw E ();
}
int bar1 (unsigned short *, int, short) throw ()
{
asm volatile ( : : : memory);
return 0;
}
void bar2 (R *) throw ()
{
asm volatile ( : : : memory);
}
void bar3 (R **, const unsigned short *, int) throw ()
{
asm volatile ( : : : memory);
}
void bar4 (R **, const char *) throw ()
{
asm volatile ( : : : memory);
}
unsigned char W::is () const
{
return 1;
}
S S::operator += (const S )
{
return *this;
}
template class C unsigned char operator = (const U , C )
{
throw 1;
}
template XY::X ();
template XZ::X ();
template unsigned char operator = (const U , XZ );
template XY::X (W const );
template Y *XY::operator- () const;
X Z foo () throw ()
{
X Z a;
X Y b;
try
{
b = X Y (baz1 (S::sfn3 (defg)));
}
catch (E )
{
}
if (b.is ())
{
for (int n = 0; n 10; n++)
{
S c = S::sfn3 (abcd);
c += S::sfn2 (n);
X Z d;
try
{
fprintf (stderr, trying %d\n, n);
if ((b-yfn1 (c) = d))
if (d.is ())
{
fprintf (stderr, failure1 on %d\n, n);
a = baz2 (d);
if (a.is ())
break;
}
fprintf (stderr, failure2 on %d\n, n);
}
catch (...)
{
void *p;
asm volatile (movl %%esp, %0 : =r (p));
fprintf (stderr, caught %d %p\n, n, p);
}
}
}
return a;
}
int
main ()
{
foo ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #44 from bkoz at gcc dot gnu dot org 2008-06-02 20:20 --- Either make -fno-exceptions unconditionally always only execute the try block via frontend support (and not only if you happen to include some libstdc++ header) This is my very strong preference. -fno-exceptions should be completely defined by cc1plus. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/36426] New: Compiling tiny prog: Stack overflow; uses PROCEDURE
The following valid program causes gfortran to use more and more stack memory. abstract interface function foo(x) character(len=len(x)) :: foo,x end function foo end interface character(len=20) :: str procedure(foo) :: bar str = bar(Hello) end -- Summary: Compiling tiny prog: Stack overflow; uses PROCEDURE Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #45 from paolo dot carlini at oracle dot com 2008-06-02 20:59 --- Frankly, at this point in the history of this issue, I don't have a strong opinion. If we decide for the library-only solution, I can do it quickly, just let me know. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/36425] Option -mno-isel not working
--- Comment #3 from edmar at freescale dot com 2008-06-02 21:18 --- Created an attachment (id=15716) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15716action=view) Modified patch Wouldn't it better then, to remove the duplicate code from linuspe.h and eabispe.h ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug target/35788] MIPS stack overflow caused by addui instruction
--- Comment #11 from derrick_chi at msn dot com 2008-06-02 21:19 --- The final response to this posting has cleared up the issue. I had improperly implemented the addi and addui instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
[Bug c++/36404] [4.2/4.3/4.4 regression] ICE with invalid enum
--- Comment #2 from paolo at gcc dot gnu dot org 2008-06-02 21:28 --- Subject: Bug 36404 Author: paolo Date: Mon Jun 2 21:27:35 2008 New Revision: 136295 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136295 Log: /cp 2008-06-02 Paolo Carlini [EMAIL PROTECTED] PR c++/36404 * pt.c (push_template_decl_real): Consistently return error_mark_node on error. /testsuite 2008-06-02 Paolo Carlini [EMAIL PROTECTED] PR c++/36404 * g++.dg/template/crash79.C: New. * g++.dg/other/pr28114.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/template/crash79.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/pr28114.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36404
[Bug target/36425] Option -mno-isel not working
--- Comment #4 from joseph at codesourcery dot com 2008-06-02 21:34 --- Subject: Re: Option -mno-isel not working On Mon, 2 Jun 2008, edmar at freescale dot com wrote: Wouldn't it better then, to remove the duplicate code from linuspe.h and eabispe.h ? It would be best for powerpc-eabispe and powerpc-linux-gnuspe not to need special headers, but instead to be powerpc-eabi / powerpc-linux-gnu + e500.h plus --with=cpu=8540 (or --with-cpu=8548 for E500 double), and for the vxworks.h logic to enable various E500 options when an E500 CPU is selected to apply for all targets supporting E500. Yes, it should be possible to remove the duplicate isel settings without doing all that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug c++/36404] [4.2/4.3 regression] ICE with invalid enum
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-02 21:28 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE |with invalid enum |with invalid enum http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36404
[Bug target/36425] Option -mno-isel not working
--- Comment #5 from edmar at freescale dot com 2008-06-02 21:46 --- Created an attachment (id=15717) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15717action=view) More complete patch Ok. Is it ready to commit now ? Thanks Edmar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36425
[Bug fortran/36361] attribute declaration outside of INTERFACE body
--- Comment #6 from janus at gcc dot gnu dot org 2008-06-02 21:51 --- Subject: Bug 36361 Author: janus Date: Mon Jun 2 21:50:23 2008 New Revision: 136296 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136296 Log: 2008-06-02 Janus Weil [EMAIL PROTECTED] PR fortran/36361 * symbol.c (gfc_add_allocatable,gfc_add_dimension, gfc_add_explicit_interface): Added checks. * decl.c (attr_decl1): Added missing var_locus. * parse.c (parse_interface): Checking for errors. 2008-06-02 Janus Weil [EMAIL PROTECTED] PR fortran/36361 * gfortran.dg/interface_24.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/interface_24.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36361
[Bug fortran/36361] attribute declaration outside of INTERFACE body
--- Comment #7 from janus at gcc dot gnu dot org 2008-06-02 21:53 --- Fixed with r136296. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36361
[Bug target/34879] __builtin_setjmp / __builtin_longjmp fails stack frame address with O2, O3 and Os
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-06-02 22:09 --- Subject: Bug 34879 Author: hutchinsonandy Date: Mon Jun 2 22:08:25 2008 New Revision: 136297 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136297 Log: PR target/34879 * config/avr/avr.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Redefine. (avr_builtin_setjmp_frame_value): New function. * config/avr/avr.md (nonlocal_goto_receiver): Define. (nonlocal_goto): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34879
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #46 from bkoz at gcc dot gnu dot org 2008-06-02 22:27 --- To clarify, I would like to see this solution come into being: 1) -fno-exceptions This flag turns off C++ exception handling support, which is indicated at compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try, catch, or throw produces an error. As a result, use of most C++ includes will fail. 2) -ftransform-exceptions This flag transforms the C++ language such that the keywords try, catch, and throw change meaning. In particular, try blocks are executed as if transformed into if (true), catch blocks are executed as if transformed into if (false), and throw expressions are discarded. Although this will compile C++ code that uses exceptions, please note that the resulting error handling and code paths are decidedly different and is almost certainly not what the original authors intended. At this point, exception_defines.h can just get junked, __throw_exception_again mechanically changed into throw, documentation updated that reprobates that had been happily using -fno-exceptions should just use -ftransform-exceptions, etc. There will be bitching about this change of course, but separating out these two things will be a blessing for GNU users. I believe this solution would fix the problem for all the various communities: 1) C++ purists who want to be able to use all the C++ keywords without increasing levels of macro uglification 2) C hackers that want to write pseudo C++, or take existing C++ code and run it without exceptions 3) C++ and ObjC++ people who want accurate diagnostics with and without -fno-exceptions will get them. Perhaps this would solve Howard's issue with -fno-exceptions C++ code and ObjC++ code that uses exceptions, but I don't really understand that issue. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used
--- Comment #4 from schwab at suse dot de 2008-06-02 22:37 --- Could you please submit your patch to [EMAIL PROTECTED], including a ChangeLog entry and stating how you tested it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36134
[Bug middle-end/36416] internal compiler error: in simplify_subreg_concatn, at lower-subreg.c:398
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-02 22:48 --- Next time, please attach and not copy and paste the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36416
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #47 from sebor at roguewave dot com 2008-06-02 23:08 ---
(In reply to comment #46)
[...]
2) -ftransform-exceptions
should catch(X) expand into else if (false) rather than just if (false)?
That said, I don't think there is a way to do this using the preprocessor
alone. Consider that
try { foo (); }
catch (SomeException ex) {
puts (ex.what ());
}
will preprocess to:
try { foo (); }
if (false) {
puts (ex.what ()); // ex undefined
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/36223] IV-opt is not optimal for mips
--- Comment #4 from hp at gcc dot gnu dot org 2008-06-02 23:11 --- n -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug middle-end/36416] internal compiler error: in simplify_subreg_concatn, at lower-subreg.c:398
--- Comment #2 from permezel at mac dot com 2008-06-02 23:37 --- There is no means to add attachments from the initial bug creation screen. Accordingly, you might expect everyone to create at least their initial bug by copy and paste, as we run thru the list of what is required in a bug submission -- a big list of stuff and no obvious means to add as an attachment. Next time, I might remember that the attach option is hidden, but I cannot guarantee this. So much to remember, so few brain cells. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36416
[Bug target/34879] __builtin_setjmp / __builtin_longjmp fails stack frame address with O2, O3 and Os
--- Comment #3 from eric dot weddington at atmel dot com 2008-06-02 23:48 --- Fixed in 4.4.0. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34879
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #48 from sebor at roguewave dot com 2008-06-03 00:07 --- FWIW, let me throw out a suggestion for an implementation of Benjamin's (2) in the C++ front end: 1. try is a no-op 2. catch blocks are syntax-checked but eliminated as dead code 3. throw checks to see if a user-defined handler is installed and if so, calls it with useful arguments (e.g., the what() string); if no handler is installed or if it returns, std::terminate() is called 4. function exception specification is diagnosed as a warning but otherwise ignored (libc, libsupc++, and libstdc++ header should compile cleanly) libsupc++ provides a __set_xxx() function to let users install the handler. AFAIK, IBM XLC++ implements 1, 2, and 4 when -qnoeh is used. Apache stdcxx implements 3 for exceptions thrown by the library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #2 from echristo at apple dot com 2008-06-03 00:37 --- Confirmed. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 00:37:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-06-03 02:16
---
Tobias, I think it needs to go farther down to just before here:
/* Select a width if none was specified. The idea here is to always
print something. */
The standard says to ignore the w.d in the G descriptor, so I think we want to
be past after this:
if (m == 0 n == 0)
{
if (w == 0)
w = 1;
p = write_block (dtp, w);
if (p == NULL)
return;
memset (p, ' ', w);
goto done;
}
Otherwise w will get set to 1 and not get ignored.
Also you example uses a0 which is also rejected. I have a patch for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
[Bug driver/36417] On Vista, driver can't find collect2
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-03 03:17 --- Although config/mh-mingw has BOOT_CFLAGS += -D__USE_MINGW_ACCESS as a fix for PR33281, CFLAGS_FOR_TARGET for mingw32 also requires this define, else libiberty's make_relative_prefix won't work on Vista. make_relative_prefix is used by driver to determine and set environment variable GCC_EXEC_PREFIX. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 03:17:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36417
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-06-03 04:09 --- I think we need fix a0 as well. I am curious if this is F2008 specific features so that we should deal with -std=f95. Time to read the standards again. :) I will fix this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 04:09:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug middle-end/36416] internal compiler error: in simplify_subreg_concatn, at lower-subreg.c:398
--- Comment #3 from permezel at mac dot com 2008-06-03 03:51 --- Subject: Re: internal compiler error: in simplify_subreg_concatn, at lower-subreg.c:398 OK, pending remembrance. I really did search in vain for an attach option. It is not obvious that there would be later opportunity to attach. Some damn bug- reporting forms give you one shot and that is it. On 2008-Jun-03, at 8:48 AM, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-02 22:48 --- Next time, please attach and not copy and paste the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36416 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. --- Comment #4 from permezel at mac dot com 2008-06-03 03:51 --- Created an attachment (id=15718) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15718action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36416
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-06-03 04:32 --- Oh this explains why the PS3 toolchain works, we override access in libiberty to and out the the bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug driver/36417] On Vista, driver can't find collect2
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-03 04:30 --- *** This bug has been marked as a duplicate of 35916 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36417
[Bug driver/35916] problem running GCC under Vista with relocated directory
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-03 04:31:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-06-03 04:30 --- *** Bug 36417 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug fortran/36420] Fortran 2008: g0 edit descriptor
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-03 05:35 --- G0 is Fortran 2008 A0 is _no_ Fortran (90 to 2008): C1006 (R1007) w shall be zero or positive for the I, B, O, Z, F, and G edit descriptors. w shall be positive for all other edit descriptors. (from Fortran 2008). But G0 should be rejected at compile-time with -std=f95/f2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36420
[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-03 05:28 --- The standard says to ignore the w.d in the G descriptor No, it only says to ignore the .d part. Gw.d is equivalent to Iw (and not to Iw.d). Also you example uses a0 which is also rejected. a0 is invalid as Aw, w 0. I pasted the wrong file. (A0 has the problem that the error message is strange, see PR 36422.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36421
