[Bug middle-end/28185] New: SIGBUS on IA64 maybe caused by memcpy I
test.c:
#include stdio.h
#include sys/types.h
#include sys/shm.h
int main()
{
int i = 0;
int shmid[3];
void *addr[3];
for (i=0; i3; i++) {
shmid[i] = shmget(IPC_PRIVATE, 256*1024*1024ULL,
SHM_HUGETLB|IPC_CREAT|SHM_R|SHM_W);
if (shmid[i] 0) {
perror(shmget);
break;
}
}
addr[0] = shmat(shmid[0], NULL, SHM_RND | SHM_UNLOCK);
printf(addr0 is %lx\n, addr[0]);
addr[1] = shmat(shmid[1], (void *)addr[0]+256 * 1024 *1024ULL, SHM_RND |
SHM_UNLOCK);
printf(addr1 is %lx\n, addr[1]);
memcpy((void *)addr[1], (void *)addr[0], 256*1024*1024ULL);
addr[2] = shmat(shmid[2], NULL, SHM_RND | SHM_UNLOCK);
printf(addr2 is %lx\n, addr[2]);
memset((void *)addr[2], 0, 256*1024*1024ULL);
}
gcc test.c -o test
./test
I did't add shmdt and shmctl, because it will be interrupted by SIGBUS.
It's OK on EM64T with gcc v3.4.4. And it's also OK on IA64 with gcc v3.3.3.
But if I use gcc v3.4.4 on IA64, sigbus error happens.
--
Summary: SIGBUS on IA64 maybe caused by memcpy I
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: snowingbear at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28185
[Bug c++/26671] [4.0/4.1/4.2 Regression] Missing warning: reference to local variable returned
--- Comment #2 from pluto at agmk dot net 2006-06-28 08:56 ---
following testcase doesn't generate warning in 4.1.2svn.
3.3.6 works fine.
#include string
std::string const foo()
{
std::string tab[ 1 ] = { std::string( text ) };
int const idx = 0;
return tab[ idx ];
}
--
pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26671
[Bug libfortran/28184] time intrinsics resolution only one second
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-06-28 09:52 --- The mingw runtime library now has a gettimeofday function which should give resolution to usec. When libgfortran is configured with the latest mingw runtime package, gettimeofday is found and used. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28184
[Bug middle-end/28185] SIGBUS on IA64 maybe caused by memcpy I
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 11:13 --- Can you try 4.0.3 or 4.1.1 as 3.4.x is no longer being maintained? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28185
[Bug target/28183] [4.0/4.1/4.2 regression] assembler error FATAL: can't close x.o on m68k with new binutils
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-28 11:15 --- (In reply to comment #2) That would almost mean as is being miscompiled on m68k. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug c++/28182] [4.0/4.1/4.2 Regression] Bad behaviour when missing typename keyword.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 11:21 --- (In reply to comment #0) Sorry if it is ill-built bugreport, this is my first one. This bug report was reported correctly and actually it is very useful. Anyways confirmed, still a bug in 4.0.x, 4.1.x and the trunk and a regression from 3.4.0 which did not ICE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|Windows XP (cygwin) | GCC target triplet|Windows XP (cygwin) | Keywords||ice-on-invalid-code Known to fail||3.4.4 4.0.3 4.1.0 4.2.0 Known to work||3.4.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-06-28 11:21:15 date|| Summary|Bad behaviour when missing |[4.0/4.1/4.2 Regression] Bad |typename keyword. |behaviour when missing ||typename keyword. Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28182
[Bug libfortran/28184] time intrinsics resolution only one second
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-28 12:11 --- On my system, I have the lastest mingw runtime (from the www.mingw.org download page): mingw-runtime-3.9.tar.gz341 kb Oct 27, 200517:10 and libgfortran configury does not find gettimeofday. Are you refering to a mingw-runtime version not yet released? -- fxcoudert 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=28184
[Bug other/28187] New: '-O2 -fwrapv' exhausts memory.
[ i486 ] gcc -O2 -fno-strict-aliasing -fwrapv -march=i486 -ggdb -DHAVE_POSIX_REGCOMP -c -o fetch.o fetch.c cc1: out of memory allocating 4064 bytes after a total of 1292098548 bytes [ powerpc ] gcc -O2 -fno-strict-aliasing -fwrapv -fsigned-char -ggdb -DHAVE_POSIX_REGCOMP -c -o fetch.o fetch.c cc: Internal error: Killed (program cc1) flags to reporduce bug: '-O2 -fwrapv -march=i486' note that e.g. with -march=i686 it works fine. (gdb) bt #0 0x006bd510 in ggc_alloc_stat () #1 0x006a3e14 in make_node_stat () #2 0x006a6c76 in build2_stat () #3 0x00562056 in fold_build2_stat () #4 0x0055c83c in fold_binary () #5 0x00562040 in fold_build2_stat () #6 0x006c5adf in extract_range_from_assert () #7 0x006c6dcb in extract_range_from_expr () #8 0x006c9e9e in vrp_visit_assignment () #9 0x006cabfd in vrp_visit_stmt () #10 0x004a08f8 in simulate_stmt () #11 0x004a0bfa in process_ssa_edge_worklist () #12 0x004a1916 in ssa_propagate () #13 0x006cc3a4 in execute_vrp () #14 0x006c0199 in execute_one_pass () #15 0x006c022c in execute_pass_list () #16 0x006c0240 in execute_pass_list () #17 0x0045d12e in tree_rest_of_compilation () #18 0x0040cac3 in c_expand_body () #19 0x006fa50f in cgraph_expand_function () #20 0x006fa646 in cgraph_expand_all_functions () #21 0x006faa6b in cgraph_optimize () #22 0x0040debf in c_write_global_declarations () #23 0x006a2419 in compile_file () #24 0x006a38ed in do_compile () #25 0x006a394e in toplev_main () #26 0x0044a601 in main () -- Summary: '-O2 -fwrapv' exhausts memory. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: 486, powerpc GCC host triplet: 486, powerpc GCC target triplet: 486, powerpc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug other/28187] '-O2 -fwrapv' exhausts memory.
--- Comment #1 from pluto at agmk dot net 2006-06-28 12:46 --- Created an attachment (id=11768) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11768action=view) i486 precompiled testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-28 13:22 --- (In reply to comment #1) John, Have all these errors just appeared or do they go back to the era of actual_array_constructor_1.f90; ie 04/04/06? The reason that I ask is that I am wondering if this is an incipient bug that is exposed by the fixes or if we are progressively adding fixes that are wrong in some way. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug libfortran/28184] time intrinsics resolution only one second
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-28 14:32 --- (In reply to comment #2) mingw-runtime-3.9.tar.gz341 kb Oct 27, 200517:10 There was in fact a mingw-runtime-3.10 release, but it's not yet on the appropriate mingw.org page (it's on the sf.net file list, however). It's indeed fixed. I upload today the new binaries. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28184
[Bug libmudflap/28188] New: dynamic linkage error for shared libraries compiled and linked against libmudflapth
I'm building a shared library with libpthread and libmudflapth support. Flags used to compile are: -fstack-protector -fmudflapth Flags used to link are: -lmudflapth When trying to dlopen the shared lib at runtime I get: symbol lookup error: /home/melfar/gcc4/lib/libmudflapth.so.0: undefined symbol: _start and the lib fails to open. Is multithreaded mudflap currently supported for shared libraries? -- Summary: dynamic linkage error for shared libraries compiled and linked against libmudflapth Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: melfar at gmail dot com GCC host triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28188
[Bug libgcj/28189] New: [4.1/4.2 Regression] Many libjava execution tests time out on Tru64 UNIX
Between 20050805 and 20060208, many libjava execution tests started to time out on Tru64 UNIX (both V4.0F and V5.1B), as can be seen comparing the following test results: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00708.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00899.html While the current 4.0 branch is fine http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01353.html both the 4.1 branch and mainline still suffer from the problem: http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00817.html http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00818.html This is a serious regression and can cause testing to take about 5 days. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap and test as described above. -- Summary: [4.1/4.2 Regression] Many libjava execution tests time out on Tru64 UNIX Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28189
arm-elf-gcc 4.0.3: ICE when compiling crtstuff.c
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC -msingle-pic-base fails. I had no trouble compiling GCC 4.1.1. Cheers, Shaun make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/ -isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include \ AR_FOR_TARGET=arm-elf-ar \ AR_CREATE_FOR_TARGET=arm-elf-ar rc \ AR_EXTRACT_FOR_TARGET=arm-elf-ar x \ AR_FLAGS_FOR_TARGET= \ CC=gcc CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES= \ LIBGCC2_CFLAGS=-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -mthumb -fPIC -msingle-pic-base \ MULTILIB_CFLAGS= -mthumb -fPIC -msingle-pic-base T=thumb/pic/xip/ thumb/pic/xip/crtbegin.o thumb/pic/xip/crtend.o thumb/pic/xip/crti.o thumb/pic/xip/crtn.o make[3]: Entering directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' /home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/-isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include -O2-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -Ithumb/pic/xip -I../../gcc -I../../gcc/thumb/pic/xip -I../../gcc/../include -I../../gcc/../libcpp/include -mthumb -fPIC -msingle-pic-base -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -Dinhibit_libc -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o thumb/pic/xip/crtbegin.o ../../gcc/crtstuff.c: In function 'frame_dummy': ../../gcc/crtstuff.c:325: internal compiler error: in thumb_find_work_register,at config/arm/arm.c:3140 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [thumb/pic/xip/crtbegin.o] Error 1 make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[2]: *** [extrathumb_pic_xip] Error 2 make[2]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make: *** [all-gcc] Error 2
[Bug libgcj/28190] New: [4.2 Regression] libjava bootstrap failure on IRIX 6.5: stdint.h misdetection
Since at least 20060503, libjava fails to bootstrap on IRIX 6.5.28: /vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc/xgcc -shared-libgcc -B/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc -nostdinc++ -L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src -L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src/.libs -B/vol/gcc/mips-sgi-irix6.5/bin/ -B/vol/gcc/mips-sgi-irix6.5/lib/ -isystem /vol/gcc/mips-sgi-irix6.5/include -isystem /vol/gcc/mips-sgi-irix6.5/sys-include -mabi=32 -DHAVE_CONFIG_H -I. -I/vol/gcc/src/gcc-dist/libjava -I./include -I./gcj -I/vol/gcc/src/gcc-dist/libjava -Iinclude -I/vol/gcc/src/gcc-dist/libjava/include -I/vol/gcc/src/gcc-dist/libjava/classpath/include -Iclasspath/include -I/vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm -I/vol/gcc/src/gcc-dist/libjava/../boehm-gc/include -I../boehm-gc/include -I/vol/gcc/src/gcc-dist/libjava/libltdl -I/vol/gcc/src/gcc-dist/libjava/libltdl -I/vol/gcc/src/gcc-dist/libjava/.././libjava/../gcc -I/vol/gcc/src/g! cc-dist/libjava/../zlib -I/vol/gcc/src/gcc-dist/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -I/vol/X11/include -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/vol/gcc\ -DLIBDIR=\/vol/gcc/lib\ -DJAVA_HOME=\/vol/gcc\ -DBOOT_CLASS_PATH=\/vol/gcc/share/java/libgcj-4.2.0.jar\ -DJAVA_EXT_DIRS=\/vol/gcc/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/vol/gcc/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/vol/gcc/lib/gcj-4.2.0\ -DPATH_SEPARATOR=\:\ -DLIBGCJ_DEFAULT_DATABASE=\/vol/gcc/lib/../lib/gcj-4.2.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.2.0/classmap.db\ -DTOOLEXECLIBDIR=\/vol/gcc/lib/../lib\ -g -O2 -mabi=32 -MT java/lang/natDouble.lo -MD -MP -MF java/lang/.deps/natDouble.Tpo -c /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc -DPIC -o java/lang/.libs/natDouble.o In file included from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: classpath/include/config-int.h:327:1: warning: INT8_MIN redefined In file included from /usr/include/inttypes.h:242, from classpath/include/config-int.h:23, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: /usr/include/stdint.h:64:1: warning: this is the location of the previous definition In file included from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: classpath/include/config-int.h:328:1: warning: INT16_MIN redefined In file included from /usr/include/inttypes.h:242, from classpath/include/config-int.h:23, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: /usr/include/stdint.h:65:1: warning: this is the location of the previous definition In file included from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: classpath/include/config-int.h:329:1: warning: INT32_MIN redefined In file included from /usr/include/inttypes.h:242, from classpath/include/config-int.h:23, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: /usr/include/stdint.h:66:1: warning: this is the location of the previous definition In file included from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: classpath/include/config-int.h:330:1: warning: INT64_MIN redefined In file included from /usr/include/inttypes.h:242, from classpath/include/config-int.h:23, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/mprec.h:33, from /vol/gcc/src/gcc-dist/libjava/classpath/native/fdlibm/fdlibm.h:29, from /vol/gcc/src/gcc-dist/libjava/java/lang/natDouble.cc:26: /usr/include/stdint.h:67:1: warning: this is the location of
[Bug c/28191] New: double comparisions are broken when value is returned from function
Hi,
This looks like floating point rounding problem but it's not. Please review the
following testcase:
#include stdio.h
double func(double p) {
return 1.097986768 * 7654 / 4.5678913 + 1/p;
}
int main()
{
double PARAM = 3.0001;
double aVal = func(PARAM);
double bVal = func(PARAM);
if (aVal bVal) {
printf(1\n);
} else {
printf(0\n);
}
if (func(PARAM) func(PARAM)) {
printf(1\n);
} else {
printf(0\n);
}
}
Running this program compiled with gcc 4.1.0 (and 4.0.1 as well) prints:
0
1
First answer (0) is right (X X == false), but second is wrong.
IMHO it is very serious problem, especially for complicated computional
algorithms.
--
Summary: double comparisions are broken when value is returned
from function
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rozenman at gmail dot com
GCC host triplet: Linux tin 2.6.15-1.2054_FC5smp #1 SMP Tue Mar 14
16:05:46 EST 20
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28191
[Bug c/28191] double comparisions are broken when value is returned from function
--- Comment #1 from rozenman at gmail dot com 2006-06-28 15:46 --- Created an attachment (id=11769) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11769action=view) Testcase program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28191
[Bug c/28193] New: config/arm/arm.c:3140 ICE
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC -msingle-pic-base fails. I had no trouble compiling GCC 4.1.1. Cheers, Shaun make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/ -isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include \ AR_FOR_TARGET=arm-elf-ar \ AR_CREATE_FOR_TARGET=arm-elf-ar rc \ AR_EXTRACT_FOR_TARGET=arm-elf-ar x \ AR_FLAGS_FOR_TARGET= \ CC=gcc CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES= \ LIBGCC2_CFLAGS=-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -mthumb -fPIC -msingle-pic-base \ MULTILIB_CFLAGS= -mthumb -fPIC -msingle-pic-base T=thumb/pic/xip/ thumb/pic/xip/crtbegin.o thumb/pic/xip/crtend.o thumb/pic/xip/crti.o thumb/pic/xip/crtn.o make[3]: Entering directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' /home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/-isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include -O2-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -Ithumb/pic/xip -I../../gcc -I../../gcc/thumb/pic/xip -I../../gcc/../include -I../../gcc/../libcpp/include -mthumb -fPIC -msingle-pic-base -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -Dinhibit_libc -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o thumb/pic/xip/crtbegin.o ../../gcc/crtstuff.c: In function 'frame_dummy': ../../gcc/crtstuff.c:325: internal compiler error: in thumb_find_work_register,at config/arm/arm.c:3140 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [thumb/pic/xip/crtbegin.o] Error 1 make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[2]: *** [extrathumb_pic_xip] Error 2 make[2]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make: *** [all-gcc] Error 2 -- Summary: config/arm/arm.c:3140 ICE Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sjackman at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug c/28194] New: R_ARM_GOTOFF32 breaks execute-in-place
Execute-in-place (XIP) code, commonly used with uClinux, places the .text
section in flash and the .data section in RAM. GCC 4.1 emits R_ARM_GOTOFF32
relocations for symbols in the .text segment relative to the GOT, which is in
the .data segment. This new behaviours breaks XIP. See the following diff,
which illustrates this new behaviour.
Cheers,
Shaun
$ cat f.c
void g(void (*h)(void)) {}
static void f(void) { g(f); }
$ diff -u f.s-4.0.3 f.s-4.1.1
--- f.s-4.0.3 2006-06-28 09:32:54.044964568 -0600
+++ f.s-4.1.1 2006-06-28 08:55:49.880089024 -0600
@@ -8,11 +8,12 @@
.type g, %function
g:
push{r7, lr}
- mov r7, sp
sub sp, sp, #4
- sub r3, r7, #4
+ add r7, sp, #0
+ mov r3, r7
str r0, [r3]
mov sp, r7
+ add sp, sp, #4
@ sp needed for prologue
pop {r7, pc}
.size g, .-g
@@ -22,10 +23,9 @@
.type f, %function
f:
push{r7, lr}
- mov r7, sp
+ add r7, sp, #0
ldr r3, .L5
add r3, r3, sl
- ldr r3, [r3]
mov r0, r3
bl g
mov sp, r7
@@ -34,6 +34,6 @@
.L6:
.align 2
.L5:
- .word f(GOT)
+ .word f(GOTOFF)
.size f, .-f
- .ident GCC: (GNU) 4.0.3
+ .ident GCC: (GNU) 4.1.1
--
Summary: R_ARM_GOTOFF32 breaks execute-in-place
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
[Bug target/27827] [4.0/4.1/4.2 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #25 from steven at gcc dot gnu dot org 2006-06-28 17:30 --- Pure luck or not, this is a regression. -- steven at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i?86-*-*, x86_64-*-*|i386, x86_64 Last reconfirmed|2006-06-01 08:43:34 |2006-06-28 17:30:40 date|| Summary|gcc 4 produces worse x87|[4.0/4.1/4.2 Regression] gcc |code on all platforms than |4 produces worse x87 code on |gcc 3 |all platforms than gcc 3 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c/28193] config/arm/arm.c:3140 ICE
--- Comment #1 from sjackman at gmail dot com 2006-06-28 17:36 --- Created an attachment (id=11772) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11772action=view) Backport thumb_find_work_register from 4.1.1 2005-03-01 Nick Clifton [EMAIL PROTECTED] * config/arm/arm.c (thumb_find_work_register): Check all of the argument registers to see if they are free, and a couple of special cases where the last argument register but can be proved to be available during the function's prologue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug c/28195] New: (shift operator) does rotate operation
When shift count is the same as the length of a variable (eg, l 32 where
long int l;), this doesn't return 0, instead it returns a rotated value.
Below is assumed to return 0, but actually returns 2468.
---t2.c---(test case)
#include stdio.h
long long ll;
long l;
int
main(){
l = 1234;
ll = l 33;
printf(%lld\n, ll);
return 0;
}
--
Summary: (shift operator) does rotate operation
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tetsuji dot rai at gmail dot com
GCC build triplet: ia32 Gentoo Linux
GCC host triplet: ia32 Gentoo Linux
GCC target triplet: ia32 Gentoo Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28195
[Bug c/28195] (shift operator) does rotate operation
--- Comment #1 from falk at debian dot org 2006-06-28 17:57 --- Shifting by an amount larger than the size of a type is undefined behavior, so anything might happen. Gcc even warns about this. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28195
[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types
--- Comment #14 from jjcogliati-r1 at yahoo dot com 2006-06-28 18:02 --- This works in 4.1.0, so only 4.1.1 has this bug so far as I can tell. -- jjcogliati-r1 at yahoo dot com changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27470
[Bug c/28191] double comparisions are broken when value is returned from function
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 18:49 --- *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28191
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #82 from pinskia at gcc dot gnu dot org 2006-06-28 18:49 --- *** Bug 28191 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rozenman at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c++/27768] [4.1/4.2 regression] wrong-code with vectors
--- Comment #11 from jason at gcc dot gnu dot org 2006-06-28 19:12 --- Turns out to be a bug in alias grouping. Patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
[Bug target/27827] [4.0/4.1/4.2 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #26 from whaley at cs dot utsa dot edu 2006-06-28 19:57 --- Created an attachment (id=11773) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11773action=view) raw runs table is generated from As promised, here is the raw data I built the table out of, including a new run from the Linux/CoreDuo user, which does not materially change the table. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/28193] config/arm/arm.c:3140 ICE
--- Comment #2 from sjackman at gmail dot com 2006-06-28 20:18 --- This proposed patch does help. At the very least, it prevents the ICE on compiling crtstuff.c while compiling the toolchain. However, with this patch applied, I saw the same bug later while compiling newlib. As the comment in thumb_find_work_register suggests, the real bug is probably in thumb_compute_save_reg_mask. make[8]: Entering directory `/home/sjackman/src/toolchain/src/_build/arm-elf/thumb/pic/xip/newlib/libc/stdio' arm-elf-gcc -B/home/sjackman/src/toolchain/src/_build/arm-elf/newlib/ -isystem /home/sjackman/src/toolchain/src/_build/arm-elf/newlib/targ-include -isystem /home/sjackman/src/toolchain/src/newlib/libc/include -DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\1.14.0\ -DPACKAGE_STRING=\newlib\1.14.0\ -DPACKAGE_BUGREPORT=\\ -I. -I../../../../../../../../newlib/libc/stdio -O2 -D__NO_SYSCALLS__ -DNO_FLOATING_POINT -DHAVE_FCNTL -DHAVE_NANOSLEEP -fno-builtin -O2 -g -O2 -mthumb -fPIC -msingle-pic-base -c -o lib_a-findfp.o `test -f 'findfp.c' || echo '../../../../../../../../newlib/libc/stdio/'`findfp.c ../../../../../../../../newlib/libc/stdio/findfp.c: In function 'std': ../../../../../../../../newlib/libc/stdio/findfp.c:61: internal compiler error:in thumb_find_work_register, at config/arm/arm.c:3173 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[8]: *** [lib_a-findfp.o] Error 1 make[8]: Leaving directory `/home/sjackman/src/toolchain/src/_build/arm-elf/thumb/pic/xip/newlib/libc/stdio' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug c/28196] New: miscompiled initialization of a constant pointer reference with offset (ppc64 target)
The following code is miscompiled when using -m64 (=ppc64) target: const static double a = 1.0; const static double *b = (double*)a - 1; b[1] should be a, but it's not - there is an additional offset of 0x1 -- Summary: miscompiled initialization of a constant pointer reference with offset (ppc64 target) Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: inbox at b-q-c dot com GCC build triplet: powerpc-apple-darwin8.6 GCC host triplet: powerpc-apple-darwin8.6 GCC target triplet: powerpc-apple-darwin8.6 (ppc64) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #1 from inbox at b-q-c dot com 2006-06-28 20:44 --- Created an attachment (id=11774) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11774action=view) test case - returns 0 on success or 1 when miscompiled gcc -m64 -o gcc64bug gcc64bug.c Inspection of the a and b will show: a = 1fe8 b = 11fe0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #2 from inbox at b-q-c dot com 2006-06-28 20:47 --- The original description should state that there is an additional offset of 0x1 (it said 0x1 instead). Also this bug is reproducible with earlier version of gcc such as 4.0.1 as supplied by Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #3 from inbox at b-q-c dot com 2006-06-28 20:50 --- Created an attachment (id=11775) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11775action=view) output of gcc -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug target/28193] config/arm/arm.c:3140 ICE
--- Comment #3 from sjackman at gmail dot com 2006-06-28 20:51 --- I tried backporting thumb_compute_save_reg_mask from GCC 4.1.1 to GCC 4.0.3 without success. I'll try backporting this entire patch from svn. 2005-03-01 Nick Clifton [EMAIL PROTECTED] * config/arm/arm.c (thumb_find_work_register): Check all of the argument registers to see if they are free, and a couple of special cases where the last argument register but can be proved to be available during the function's prologue. (print_multi_reg, arm_compute_save_reg0_reg12_mask, output_return_instruction, emit_multi_reg_push, thumb_pushpop, thumb_unexpanded_epilogue): Use unsigned long as the type for the register bit-mask. (thumb_compute_save_reg_mask): Likewise. Also use thumb_find_work_register() to ensure that there is agreement about which work register is going to be used in the prologue. (thumb_output_function_prologue): Use unsigned long as the type for the register bit-mask. Also delay pushing the link register if other high registers are going to be pushed. (thumb_compute_save_reg_mask, emit_multi_reg_push, print_multi-reg, number_of_first_bit_set, thumb_pushpop): Remove redundant prototypes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-28 21:05 --- .quad _a-8 Not a GCC bug, a bug in the cctools assembler/linker, report this to Apple. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 21:14 --- I can reproduce this on the mainline with a cross to powerpc64-linux-gnu with -m32 -O2 -fwrapv. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|other |tree-optimization Keywords||memory-hog Known to fail||4.1.2 4.2.0 Known to work||4.0.1 Summary|'-O2 -fwrapv' exhausts |[4.1/4.2 Regression] '-O2 - |memory. |fwrapv' exhausts memory. Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug bootstrap/28133] Cross-compile of GCC fails with C compiler cannot create executables error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 21:16 --- Actually this is a dup of bug 25035. *** This bug has been marked as a duplicate of 25035 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28133
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-28 21:16 --- *** Bug 28133 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aweiner at lsil dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug c/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-28 21:18 --- Confirmed, we don't record in the preprocessor which keyword is used, _Complex is treated the same as __complex__. There is another bug about a similar issue with or and |. -- 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 |2006-06-28 21:18:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-28 21:21 --- PR 14875 is the related bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14875 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-28 22:00 --- Created an attachment (id=11776) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11776action=view) Fixes the problem and some The attached patch fixes the PR and fixes character valued functions in array constructors. This works: character(4), dimension(4) :: c1, c2 integer m m = 4 ! Test the original problem call foo ((/( 'a',i=1,m )/), c2) if (any(c2(:)(1:1) .ne. (/'a','a','a','a'/))) call abort () ! Now get a bit smarter call foo ((/abcd, efgh, ijkl, mnop/), c1) ! worked before call foo ((/(c1(i), i = m,1,-1)/), c2)! was broken if (any(c2(4:1:-1) .ne. c1)) call abort () ! gfc_todo: Not Implemented: complex character array constructors ! call foo ((/(c1(i)(2:3), i = 1,4)/), c2) ! Check functions in the constructor call foo ((/(achar(64+i)//achar(68+i)//achar(72+i)// achar(76+i),i=1,4 )/), c1) ! was broken if (any (c1 .ne. (/AEIM,BFJN,CGKO,DHLP/))) call abort () contains subroutine foo (chr1, chr2) character(*), dimension(:) :: chr1, chr2 chr2 = chr1 end subroutine foo end Paul PS Do not worry - I had not forgotten PR28174! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug target/28193] config/arm/arm.c:3140 ICE
--- Comment #4 from sjackman at gmail dot com 2006-06-28 22:30 --- I tried applying r95736 (2005-03-01 Nick Clifton) and r103151 (2005-08-16 Richard Earnshaw) against GCC 4.0.3. Both these patches apply cleanly (with offsets), but don't fix the problem compiling newlib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug target/28193] [4.0 only] config/arm/arm.c:3140 ICE
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-28 23:31 --- Is this a regression? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|config/arm/arm.c:3140 ICE |[4.0 only] ||config/arm/arm.c:3140 ICE Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug regression/28173] [4.1 Regression] 4.1.1 misses constant folding .
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|4.1.1 misses constant |[4.1 Regression] 4.1.1 |folding . |misses constant folding . Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28173
[Bug target/28158] ICE on complex operation with -O1 -msse
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-28 23:34 --- Is this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
[Bug target/28158] [4.2 Regression] ICE on complex operation with -O1 -msse
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-28 23:35 --- I think it was caused by: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01526.html Which means this is a 4.2 Regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE on complex operation|[4.2 Regression] ICE on |with -O1 -msse |complex operation with -O1 - ||msse Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
[Bug c/28197] New: longjmp and alloca cause bus error
I got a bus error by following program which use longjmp and __builtin_alloca
with -O0.
% cat z.c
#include setjmp.h
jmp_buf env;
void f(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
longjmp(env, 1);
}
int main()
{
if (setjmp(env) == 0) {
void *p = __builtin_alloca(4);
f(1,2,3,4,5,6,7,8);
}
return 0;
}
% ~/src/gcc/bin/gcc -E z.c z.i
% cat z.i
# 1 z.c
# 1 built-in
# 1 command line
# 1 z.c
# 1 /usr/include/setjmp.h 1 3 4
# 26 /usr/include/setjmp.h 3 4
# 1 /usr/include/machine/setjmp.h 1 3 4
# 29 /usr/include/machine/setjmp.h 3 4
# 1 /usr/include/ppc/setjmp.h 1 3 4
# 31 /usr/include/ppc/setjmp.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 32 /usr/include/ppc/setjmp.h 2 3 4
# 1 /usr/include/machine/signal.h 1 3 4
# 27 /usr/include/machine/signal.h 3 4
# 1 /usr/include/ppc/signal.h 1 3 4
# 29 /usr/include/ppc/signal.h 3 4
# 1 /usr/include/sys/appleapiopts.h 1 3 4
# 30 /usr/include/ppc/signal.h 2 3 4
typedef int sig_atomic_t;
# 50 /usr/include/ppc/signal.h 3 4
typedef enum {
REGS_SAVED_NONE,
REGS_SAVED_CALLER,
REGS_SAVED_ALL
} regs_saved_t;
# 66 /usr/include/ppc/signal.h 3 4
struct sigcontext32 {
int sc_onstack;
int sc_mask;
int sc_ir;
int sc_psw;
int sc_sp;
void *sc_regs;
};
struct sigcontext64 {
int sc_onstack;
int sc_mask;
long long sc_ir;
long long sc_psw;
long long sc_sp;
void *sc_regs;
};
struct sigcontext {
int sc_onstack;
int sc_mask;
int sc_ir;
int sc_psw;
int sc_sp;
void *sc_regs;
};
# 28 /usr/include/machine/signal.h 2 3 4
# 33 /usr/include/ppc/setjmp.h 2 3 4
struct _jmp_buf {
struct sigcontext sigcontext;
unsigned int vmask __attribute__((aligned(8)));
unsigned int vreg[32 * 4] __attribute__((aligned(16)));
};
# 82 /usr/include/ppc/setjmp.h 3 4
typedef int jmp_buf[(26 + 18*2 + 129 + 1)];
typedef int sigjmp_buf[(26 + 18*2 + 129 + 1) + 1];
extern int setjmp(jmp_buf env);
extern void longjmp(jmp_buf env, int val);
int _setjmp(jmp_buf env);
void _longjmp(jmp_buf, int val);
int sigsetjmp(sigjmp_buf env, int val);
void siglongjmp(sigjmp_buf env, int val);
void longjmperror(void);
# 30 /usr/include/machine/setjmp.h 2 3 4
# 27 /usr/include/setjmp.h 2 3 4
# 2 z.c 2
jmp_buf env;
void f(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
longjmp(env, 1);
}
int main()
{
if (setjmp(env) == 0) {
void *p = __builtin_alloca(4);
f(1,2,3,4,5,6,7,8);
}
return 0;
}
% ~/src/gcc/bin/gcc -O0 -g -v z.i
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../gcc-4.1.1/configure --prefix=/Users/akr/src/gcc
--enable-languages=c --with-as=/Users/akr/src/odcctools/bin/as
--with-ld=/Users/akr/src/odcctools/bin/ld
Thread model: posix
gcc version 4.1.1
/Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/cc1
-fpreprocessed z.i -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase z.i
-auxbase z -g -O0 -version -o /var/tmp//ccD20CPP.s
GNU C version 4.1.1 (powerpc-apple-darwin8.6.0)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 060081fe4c432c1f8e1af4cf790a4da4
/Users/akr/src/odcctools/bin/as -arch ppc -o /var/tmp//cck0sLjz.o
/var/tmp//ccD20CPP.s
/Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/collect2
-dynamic -arch ppc -weak_reference_mismatches non-weak -o a.out -lcrt1.o
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/crt2.o
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/../../..
/var/tmp//cck0sLjz.o -lgcc -lSystemStubs -lSystem
% ./a.out
zsh: bus error ./a.out
% uname -a
Darwin ppc64.tky.aist.go.jp 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7
16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc
--
Summary: longjmp and alloca cause bus error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
GCC build triplet: powerpc-apple-darwin8.6.0
GCC host triplet: powerpc-apple-darwin8.6.0
GCC target triplet: powerpc-apple-darwin8.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28197
[Bug target/28193] [4.0 only] config/arm/arm.c:3140 ICE
--- Comment #6 from sjackman at gmail dot com 2006-06-29 00:01 --- Applying the patch from r103277 fixes this bug. I also had r95736 and r103151 applied against my 4.0.3 tree at the time. So, I don't know if r103277 alone is sufficient. r103277 was meant to close PR target/23473, so this bug may be a duplicate of #23473. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug target/28193] [4.0 only] config/arm/arm.c:3140 ICE
--- Comment #7 from sjackman at gmail dot com 2006-06-29 00:10 --- Subject: Re: [4.0 only] config/arm/arm.c:3140 ICE On 28 Jun 2006 23:31:22 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-28 23:31 --- Is this a regression? ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193 I haven't tested any version of GCC earlier than 4.0.3 for this bug, so I don't know if it's a regression. I was testing svn versions after 4.0.3 and before 4.1.0 to discover when this bug was fixed. It appears it was fixed in r103277. Cheers, Shaun -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193
[Bug target/28137] make check gets 10 FAIL reports with gcc.dg/c99-typespec-1.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-29 00:30 --- (In reply to comment #4) FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED] Yes this one is known. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137
[Bug c++/27768] [4.1/4.2 regression] wrong-code with vectors
--- Comment #12 from jason at gcc dot gnu dot org 2006-06-29 01:12 --- Subject: Bug 27768 Author: jason Date: Thu Jun 29 01:12:20 2006 New Revision: 115062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115062 Log: PR c++/27768 * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add may_aliases already in the tag's annotations to the bitmap. Added: trunk/gcc/testsuite/g++.dg/opt/alias4.C Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
[Bug c++/27424] [4.0/4.1/4.2 regression] Valid template-template-parameter rejected
--- Comment #2 from jason at gcc dot gnu dot org 2006-06-29 01:27 --- Subject: Bug 27424 Author: jason Date: Thu Jun 29 01:27:17 2006 New Revision: 115063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115063 Log: PR c++/27424 * pt.c (convert_template_argument): Pass all template arguments on to coerce_template_template_parms. Added: trunk/gcc/testsuite/g++.dg/template/ttp20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27424
[Bug c++/18698] [4.0/4.1/4.2 regression] Error message using using for code not using using ;-)
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-12 17:53:52 |2006-06-29 01:28:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18698
[Bug target/28197] longjmp and alloca cause bus error at -O0
--- Comment #1 from akr at m17n dot org 2006-06-29 01:49 ---
I found a way to reproduce the bus error with -O2 as well as -O0.
% cat z.c
#include setjmp.h
jmp_buf env;
int i;
int main()
{
if (setjmp(env) == 0) {
char *p = __builtin_alloca(1024);
for (i = 0; i 1024; i++) {
p[i] = 0;
}
longjmp(env, 1);
}
return 0;
}
Z:[EMAIL PROTECTED] ~/src/gcc/bin/gcc -O2 -v z.c
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../gcc-4.1.1/configure --prefix=/Users/akr/src/gcc
--enable-languages=c --with-as=/Users/akr/src/odcctools/bin/as
--with-ld=/Users/akr/src/odcctools/bin/ld
Thread model: posix
gcc version 4.1.1
/Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/cc1 -quiet -v
-D__DYNAMIC__ z.c -fPIC -quiet -dumpbase z.c -auxbase z -O2 -version -o
/var/tmp//ccCHTcUf.s
ignoring nonexistent directory
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/../../../../powerpc-apple-darwin8.6.0/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/Users/akr/src/gcc/include
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C version 4.1.1 (powerpc-apple-darwin8.6.0)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 060081fe4c432c1f8e1af4cf790a4da4
/Users/akr/src/odcctools/bin/as -arch ppc -o /var/tmp//ccsOCM5w.o
/var/tmp//ccCHTcUf.s
/Users/akr/src/gcc/libexec/gcc/powerpc-apple-darwin8.6.0/4.1.1/collect2
-dynamic -arch ppc -weak_reference_mismatches non-weak -o a.out -lcrt1.o
/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/crt2.o
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1
-L/Users/akr/src/gcc/lib/gcc/powerpc-apple-darwin8.6.0/4.1.1/../../..
/var/tmp//ccsOCM5w.o -lgcc -lSystemStubs -lSystem
% ./a.out
zsh: bus error ./a.out
% ~/src/gcc/bin/gcc -O0 z.c
% ./a.out
zsh: bus error ./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28197
[Bug target/27827] [4.0/4.1/4.2 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #27 from hjl at lucon dot org 2006-06-29 02:32 --- Created an attachment (id=11777) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11777action=view) An integer loop I changed the loop from double to long long. The 64bit code generated by gcc 4.0 is 10% slower than gcc 3.4 on Nocona: /usr/gcc-3.4/bin/gcc -m32 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-3.4/bin/gcc -m32 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-3.4/bin/gcc -m32 -fomit-frame-pointer -O -o xmm_gcc mmbench.o gemm_atlas.o rm -f *.o /usr/gcc-4.0/bin/gcc -m32 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-4.0/bin/gcc -m32 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-4.0/bin/gcc -m32 -fomit-frame-pointer -O -o xmm_gc4 mmbench.o gemm_atlas.o rm -f *.o echo GCC 3.x performance: GCC 3.x performance: ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60250 0.381 283.51 echo GCC 4.x performance: GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60250 0.389 277.68 gnu-16:pts/2[5] make ~/bugs/gcc/27827/loop /usr/gcc-3.4/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-3.4/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-3.4/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -o xmm_gcc mmbench.o gemm_atlas.o rm -f *.o /usr/gcc-4.0/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c mmbench.c /usr/gcc-4.0/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -c gemm_atlas.c /usr/gcc-4.0/bin/gcc -DREPS=1000 -fomit-frame-pointer -O -o xmm_gc4 mmbench.o gemm_atlas.o rm -f *.o echo GCC 3.x performance: GCC 3.x performance: ./xmm_gcc ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.172 2512.01 echo GCC 4.x performance: GCC 4.x performance: ./xmm_gc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 60 1000 0.193 2238.68 So the problem may be also loop related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/27827] [4.0/4.1/4.2 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #28 from whaley at cs dot utsa dot edu 2006-06-29 04:17 --- Guys, If you are looking for the reason that the new code might be slower, my feeling from the benchmark data is that involves hiding the cost of the loads. Notice that, except for the cases where the double exceeds the cache, the single precision gcc4 code always gets a greater percentage of gcc3's numbers than double for each platform. This is the opposite of what you expect if the problem is purely computational, but exactly what you expect if the problem is due to memory costs (since single has half the memory cost). If I were forced to take a WAG as to what's going on, I would guess it has to do with the more dependencies in the new code sequence confusing tomasulo's or register renaming. I haven't worked it out in detail, but scope the two competing code sequences: gcc 3gcc 4 === === fldl 32(%edx)fldl 32(%edx) fldl 32(%eax)fld %st(0) fmul %st(1),%st fmull 32(%eax) faddp %st,%st(6) faddp %st, %st(2) Note that in gcc 3, both loads are independent, and can be moved past each other and arbitrarily early in the instruction stream. The fmull would need to be broken into two instructions before a similar freedom occurs. I'm not sure how the fp stack handling is done in hardware, but the fact that you've replaced two independent loads with 3 forced-order instructions cannot be beneficial. At the same time, it is difficult for me to see how the new sequence can be better. We've got the same number of loads, the same number of instructions, the same register use (I think), with a forced ordering and loads you cannot advance (critical in load-happy 8-register land). I originally thought that the gcc 4 stream used one less register, but it appears to copy the edx operand twice to stack, so I'm no longer sure it has even that advantage? Just my guess, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
