[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #13 from jb at gcc dot gnu dot org 2006-03-16 08:30 --- (In reply to comment #12) The attached C program fails on IA64 because the printf rounds the last digit of MIN_LDBL down when it prints it and so it can't be read back in. The basic problem is that LDBL_MAX and LDBL_MIN (or for that matter DBL_MIN and DBL_MAX) cannot be represented exactly in decimal form so printf has to do some rounding that may make the process non-reversable when trying to go back via strtod or strtold. Ah, I see. Well, IMHO formatted IO of FOO_MAX/MIN is a rather obscure corner case, so I think a good enough solution would be to change the testcase to instead test with FOO_MAX/2 and FOO_MIN*2 (just to check that we have large enough field widths etc. and not worry about rounding out of range). But I'll ask the standards gurus on c.l.f first to make sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug fortran/24520] Temporary constant array descriptors being declared at wrong binding level.
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-03-16 08:38 --- Yes, it is not quite as spectacular as before but present nonetheless. By comparing pointer and non-pointer cases, I measure an overhead of 12 +/- 7 ns on a 2.4Ghz PIV. I have no idea why the error is so large but it bobs around, according to the size of the array; eg. for array size N = 1, it is 19ns, for N = 16 is 16ns, whilst n = 4 is only hit for 6ns. In preparing the array TRANSFER intrinsic, I have learned more about parameter passing than I like to think about. *sigh* I think it might be an easy matter to promote the case of a constant descriptor up to the procedure scope. I t has been pushed onto the TODO stack. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
[Bug libstdc++/26497] libstdc++-v3: configure: test: -lt: unary operator expected
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-03-16 08:39 --- glibcxx_gnu_ld_version is only set when building natively, but used when --with-gnu-ld which implies --enable-symvers=gnu. This is the bug. Unfortunately, GLIBCXX_CHECK_LINKER_FEATURES is a native-only test. However, even if not native, if using GNU ld one should be able to get the version and thus set glibcxx_gnu_ld_version. I suppose that is the right way to fix this. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26497
[Bug libstdc++/25409] STL mt_allocator crash in global construcutor
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-03-16 08:40 --- I'm going to check this in to libstdcxx_so_7-branch. It will be easier to test there. Please try to make a self-contained testcase for this, ie one file, no make file, etc. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug libstdc++/26497] libstdc++-v3: configure: test: -lt: unary operator expected
--- Comment #6 from ralf dot corsepius at rtems dot org 2006-03-16 09:06 --- (In reply to comment #5) Unfortunately, GLIBCXX_CHECK_LINKER_FEATURES is a native-only test. Could you explain why it is native-only? AFAIS, it tries to run the linker, which is a build-host tool at this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26497
[Bug other/26709] New: Compile of gcc 3.3.6 failed
I am unable to compile gcc 3.3.6 downloaded from mirror ftp.gwdg.de. ./configure make -j2 triggers the following errors: f/com.c: At top level: f/com.c:11080: error: conflicting types for ?ffecom_gfrt_basictype? f/com.h:236: error: previous declaration of ?ffecom_gfrt_basictype? was here This seems to be an trivial typo, I fixed it with: --- gcc-3.3.6/gcc/f/com.h 2003-03-22 16:24:51.0 +0100 +++ gcc-3.3.6-fix/gcc/f/com.h 2006-03-15 18:23:29.0 +0100 @@ -233,7 +233,7 @@ void ffecom_finish_progunit (void); tree ffecom_get_invented_identifier (const char *pattern, ...) ATTRIBUTE_PRINTF_1; -ffeinfoKindtype ffecom_gfrt_basictype (ffecomGfrt ix); +ffeinfoBasictype ffecom_gfrt_basictype (ffecomGfrt ix); ffeinfoKindtype ffecom_gfrt_kindtype (ffecomGfrt ix); void ffecom_init_0 (void); void ffecom_init_2 (void); The second error is in the java directory: gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes-DHAVE_CONFIG_H-I. -Ijava -I. -I./java -I./config -I./../include java/gjavah.c -o java/gjavah.o java/gjavah.c:49: error: static declaration of ?flag_jni? follows non-staticdeclaration java/java-tree.h:170: error: previous declaration of ?flag_jni? was here Here I don't know if the fix below is correct. At least it fixes the compile problem... ;-) --- gcc-3.3.6/gcc/java/gjavah.c 2003-03-28 23:18:48.0 +0100 +++ gcc-3.3.6-fix/gcc/java/gjavah.c 2006-03-15 18:29:42.0 +0100 @@ -46,7 +46,7 @@ static int found_error = 0; /* Nonzero if we're generating JNI output. */ -static int flag_jni = 0; +int flag_jni = 0; /* When nonzero, warn when source file is newer than matching class file. */ I hope this helps!? Please be patient with me, because this is my first bug report and fix so far. -- Summary: Compile of gcc 3.3.6 failed Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Sven dot Rebhan at gmail dot com GCC host triplet: x86, SuSE Linux 10.0, gcc 4.0.2 (SuSE version) GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26709
[Bug libfortran/26710] New: build failure on mactel: non-relocatable subtraction error for compile_options.c
For the released 4.1.0, building runtime/compile_options.c (and others) fail on i386 os x with a non-relocatable subtraction error. A simple short term workaround is to use -fno-common when building Output from cut and pasted line: /Users/Shared/gcc/./gcc/xgcc -B/Users/Shared/gcc/./gcc/ -B/usr/local/i386-apple-darwin8.5.1/bin/ -B/usr/local/i386-apple-darwin8.5.1/lib/ -isystem /usr/local/i386-apple-darwin8.5.1/include -isystem /usr/local/i386-apple-darwin8.5.1/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.1.0/libgfortran -I. -iquote../../../gcc-4.1.0/libgfortran/io -I../../../gcc-4.1.0/libgfortran/../gcc -I../../../gcc-4.1.0/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -c ../../../gcc-4.1.0/libgfortran/runtime/compile_options.c -o compile_options.o /var/tmp//ccMDk2iK.s:46:non-relocatable subtraction expression, __gfortrani_compile_options minus L003$pb /var/tmp//ccMDk2iK.s:46:symbol: __gfortrani_compile_options can't be undefined in a subtraction expression /var/tmp//ccMDk2iK.s:34:non-relocatable subtraction expression, __gfortrani_compile_options minus L002$pb After a successful build the specs are: Using built-in specs. Target: i386-apple-darwin8.5.1 Configured with: ../gcc-4.1.0/configure --enable-languages=c,c++,fortran,java Thread model: posix gcc version 4.1.0 - does not occur under ppc-apple-darwin8.5.0, even if the command line is cut and pasted across. -- Summary: build failure on mactel: non-relocatable subtraction error for compile_options.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ccb at dl dot ac dot uk GCC build triplet: i386-apple-darwin8.5.1 GCC host triplet: i386-apple-darwin8.5.1 GCC target triplet: i386-apple-darwin8.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26710
[Bug other/26709] Compile of gcc 3.3.6 failed
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-16 10:50 --- Unfortunately you are late and both the 3.3 and the 3.4 series have been dicontinued ;) So, this is at least fixed in 4.0.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26709
[Bug other/26709] Compile of gcc 3.3.6 failed
--- Comment #2 from Sven dot Rebhan at gmail dot com 2006-03-16 11:44 --- I know that i am to late, but I (and probably others) depend on this special version (for policy reasons), so I wanted to share my knowledge with others. :) EOT -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26709
[Bug bootstrap/26711] New: Compilation breaks in gcc/genattrtab.c on Mac OS X 10.2.8 on G4 with odcctools
Hardware: apple powerpc dual g4 867 MHz OS: Mac OS X 10.2.8 Jaguar Kernel: Darwin 6.8 Build platform: apple's GCC version 1151, based on gcc version 20020420 from Dec2002DevToolsCD.dmg odcctools-20060226 GCC version:4.2.0-20060311, 4.1.0 (release) Mac OS X 10.3.9 status for 4.2-20060311: builds OK % ../gcc-4.2-20060311/configure --prefix=/usr/local --program-suffix=-4.2 $ make -j 2 bootstrap . . . gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.1.0/gcc -I../../gcc-4.1.0/gcc/. -I../../gcc-4.1.0/gcc/../include -I./../intl -I../../gcc-4.1.0/gcc/../libcpp/include ../../gcc-4.1.0/gcc/ggc-common.c -o ggc-common.o gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.1.0/gcc -I../../gcc-4.1.0/gcc/build -I../../gcc-4.1.0/gcc/../include -I./../intl -I../../gcc-4.1.0/gcc/../libcpp/include -o build/genattrtab.o ../../gcc-4.1.0/gcc/genattrtab.c ../../gcc-4.1.0/gcc/ggc-common.c: In function `ggc_rlimit_bound': ../../gcc-4.1.0/gcc/ggc-common.c:681: storage size of `rlim' isn't known ../../gcc-4.1.0/gcc/ggc-common.c:681: warning: unused variable `rlim' make[2]: *** [ggc-common.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2 -save-temps .i follows in attachment. Best regards, Mirsad -- Summary: Compilation breaks in gcc/genattrtab.c on Mac OS X 10.2.8 on G4 with odcctools Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtodorov at alu dot hr GCC build triplet: powerpc-apple-darwin6.8 GCC host triplet: powerpc-apple-darwin6.8 GCC target triplet: powerpc-apple-darwin6.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711
[Bug bootstrap/26711] Compilation breaks in gcc/genattrtab.c on Mac OS X 10.2.8 on G4 with odcctools
--- Comment #1 from mtodorov at alu dot hr 2006-03-16 12:26 --- Created an attachment (id=11057) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11057action=view) generated gcc/ggc-common.i with make options + -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711
[Bug libfortran/26712] New: gfortran on mac intel runtime floating point exception when printing
All attempts to run code compiled with gfortran fail if there is a floating point print. This seems to be due to a floating point underflow exception being invoked. cat test.f program test real a a = 10.0 print *,a stop end gdb stack trace follows: (gdb) run Starting program: /Users/charlesb/a.out Reading symbols for shared libraries .++ done Program received signal EXC_ARITHMETIC, Arithmetic exception. 0x900e5158 in __gdtoa () (gdb) where #0 0x900e5158 in __gdtoa () #1 0x900e47f8 in __ldtoa () #2 0x9000c947 in __vfprintf () #3 0x9000baf0 in sprintf () #4 0x0024d968 in output_float (dtp=0xbfffefb0, f=0x400390, value=10) at ../../../gcc-4.1.0/ libgfortran/io/write.c:472 #5 0x0024e597 in write_float (dtp=0xbfffefb0, f=0xbfffef08, source=0x3ff4 Address 0x3ff4 out of bounds, len=4) at ../../../gcc-4.1.0/libgfortran/io/write.c:898 #6 0x0024e6a9 in write_real (dtp=0xbfffefb0, source=0xbfffe368 , length=1072955392) at ../../../ gcc-4.1.0/libgfortran/io/write.c:1390 #7 0x0024f06d in *__gfortrani_list_formatted_write (dtp=0xbfffefb0, type=BT_REAL, p=0xb0c0, kind=4, size=4, nelems=1) at ../../../gcc-4.1.0/libgfortran/io/write.c:1460 #8 0x002486f0 in *__gfortran_transfer_real (dtp=0xbfffefb0, p=0xb0c0, kind=4) at ../../../ gcc-4.1.0/libgfortran/io/transfer.c:1079 #9 0x1ebb in MAIN__ () at test.f:4 #10 0x1efc in main (argc=-1073745608, argv=0x1de6) at ../../../gcc-4.1.0/libgfortran/fmain.c: 18 Specs of compiler version: Using built-in specs. Target: i386-apple-darwin8.5.1 Configured with: ../gcc-4.1.0/configure --enable-languages=c,c++,fortran,java Thread model: posix gcc version 4.1.0 -- Summary: gfortran on mac intel runtime floating point exception when printing Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ccb at dl dot ac dot uk GCC build triplet: i386-apple-darwin8.5.1 GCC host triplet: i386-apple-darwin8.5.1 GCC target triplet: i386-apple-darwin8.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug c/26713] New: Stack frame allocation limited to 32k
Allocation of stack frames is limited to a maximum of 32k, regardless of how
much memory is needed by local variables. Addressing of local variables, on the
other hand, is also possible beyond the 32k limit. This can lead to
unpredictable application behavior. No compiler warning is generated. See the C
code below and the commented assembler output.
int main(void)
{
char array[32770];
array[0] = 12;
array[32769] = 34;
return 0;
}
results in:
1690 main:
1690: 27bd8020addiu sp,sp,-32736# char array[32770]
# only results in 32736
# bytes being allocated
1694: ffbe7fd8sd s8,32728(sp)
1698: ffbc7fd0sd gp,32720(sp)
169c: 27bdffc0addiu sp,sp,-64
16a0: 03a0f02dmoves8,sp
16a4: 3c1c0011lui gp,0x11
16a8: 0399e021addugp,gp,t9
16ac: 279c82a0addiu gp,gp,-32096
16b0: 2402000cli v0,12
16b4: a3c2sb v0,0(s8)# array[0]=12
16b8: 3c020001lui v0,0x1
16bc: 03c21821adduv1,s8,v0# v1=s8+65536
16c0: 24020022li v0,34
16c4: a0628001sb v0,-32767(v1) # array[65536-32767]=34
# Addressing of local
# variables is possible
# beyond the 32k
# boundary
16c8: 102dmovev0,zero
16cc: 27dd0040addiu sp,s8,64
16d0: dfbe7fd8ld s8,32728(sp)
16d4: dfbc7fd0ld gp,32720(sp)
16d8: 03e8jr ra
16dc: 27bd7fe0addiu sp,sp,32736
--
Summary: Stack frame allocation limited to 32k
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christoph dot stueckjuergen at siemens dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: mips64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26713
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #1 from ccb at dl dot ac dot uk 2006-03-16 12:35 --- I have played with this some more, and it seems to be an floating point underflow. Default configure results in FPU_HOST_HEADER=config/fpu-387.h, however, Darwin on i386 uses a fenv.h that is similar to that in config/fpu-glibc.h. By editing fpu-glibc.h I can run test.f successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug target/26713] Stack frame allocation limited to 32k
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-16 12:38 --- Please try 4.0.3 or 4.1.0, the 3.4 series is no longer maintained (you may turn to your system provider though). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26713
[Bug libfortran/26710] build failure on mactel: non-relocatable subtraction error for compile_options.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 13:04 --- Fixed in 4.2.0, the port is fundamentally borken before then. This one problem was fixed by: 2006-01-11 Andrew Pinski [EMAIL PROTECTED] * config/i386/darwin.h (SUBTARGET_ENCODE_SECTION_INFO): Define. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26710
[Bug c++/26714] New: violation of [class.temporary]/5
Somebody in c.l.c++.m[1] dug out an overlooked clause in 12.2/5
[class.temporary], namely that A temporary bound to a reference member in a
constructor's ctor-initializer (12.6.2) persists until the constructor exists
The following piece of code should therefore print:
===
A()
A()
B()
~A()
~A()
main
===
however, all tested versions (gcc-3.3.6, gcc-4.0.3, gcc-4.1.0) print:
==
A()
~A()
A()
~A()
B()
main
==
// begin example
extern C int puts(const char*);
struct A
{
A() { puts(A()); }
~A() { puts(~A()); }
};
struct B
{
const A a1;
const A a2;
B() : a1(A()),a2(A()) { puts(B()); }
};
int main()
{
B b;
puts(main);
}
// end example
References:
[1] Message-ID:[EMAIL PROTECTED]
--
Summary: violation of [class.temporary]/5
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at technoboredom dot net
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26714
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 13:17 --- Hmm, I wonder if this is related to: http://lists.apple.com/archives/Darwin-dev/2006/Mar/msg00102.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug bootstrap/26711] Compilation breaks in gcc/genattrtab.c on Mac OS X 10.2.8 on G4 with odcctools
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 13:24 --- *** This bug has been marked as a duplicate of 13982 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711
[Bug bootstrap/13982] Bootstrap of gcc-3.4-20040128 on Darwin6.8/Mac OS X 10.2.8 failed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 13:24 --- *** Bug 26711 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mtodorov at alu dot hr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13982
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 13:32 --- (In reply to comment #1) I have played with this some more, and it seems to be an floating point underflow. Default configure results in FPU_HOST_HEADER=config/fpu-387.h, however, Darwin on i386 uses a fenv.h that is similar to that in config/fpu-glibc.h. Are you saying that fpu-387.h is not working correctly so you used fpu-glibc.h but modified it for darwin's fenv.h? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug bootstrap/13982] Bootstrap of gcc-3.4-20040128 on Darwin6.8/Mac OS X 10.2.8 failed
--- Comment #5 from mtodorov at alu dot hr 2006-03-16 13:35 --- Changing build_dir/gcc/auto-host.h #define HAVE_SYS_RESOURCE_H 1 makes build pass this point where it failed. This was set to #undef despite having the include in /usr/incude/sys/resource.h I guess configure script has not found it. I odn't have the knowledge of fixing the configure script, so it is a bootstrap bug after all. /* Define to 1 if you have the sys/resource.h header file. */ #ifndef USED_FOR_TARGET #define HAVE_SYS_RESOURCE_H 1 #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13982
[Bug c++/26714] violation of [class.temporary]/5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 13:39 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i586-suse-linux | GCC host triplet|i586-suse-linux | GCC target triplet|i586-suse-linux | Keywords||wrong-code Known to fail||2.95.3 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-16 13:39:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26714
[Bug other/26715] New: boostrap comparison failure (stage2?) during make bootstrap on solaris8 only?
Hi all, I've been trying upgrade our C environment on our solaris boxes to GCC4.1 Currently we're using GCC 3.4.2 from Sun Freeware's online packages. $ gcc --version gcc (GCC) 3.4.2 ... Using the same ./configure options on 4 clean sparc Solaris systems (running 2.6, 7, 8 and 9) systems I find that the make bootstrap fails on solaris 8 only. I'm configuring the source as: cd /build/gcc/compiled ; CONFIG_SHELL=/bin/ksh /build/gcc-4.1.0/configure \ --prefix=/opt/gcc \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --disable-nls \ --enable-libgcj \ --enable-languages=c,c++,objc,java make bootstrap fails on my solaris8 system complaining: Bootstrap comparison failure! ./integrate.o differs cp/semantics.o differs build/gengtype.o differs make[1]: *** [gnucompare] Error 1 make[1]: Leaving directory `/build/gcc/compiled/gcc' make: *** [bootstrap] Error 2 using 'hexdump' I have compared the two six files that differ: integrate.o 0006000 0723 000f 0300 0260 1c23 750a 6469 stage2/integrate.o 0006000 0400 0723 000f 0300 0260 1c23 750a 6469 cp/semantics.o 0028c00 8028 0100 0714 8828 stage2/cp/semantics.o 0028c00 0400 8028 0100 0714 8828 build/gengtype.o0014c00 b418 0100 0057 1800 00b4 1800 00ec stage2/build/gengtype.o 0014c00 0400 b418 0100 0057 1800 00b4 1800 00ec There is a one bit difference between the pairs! I'm sorry if I've left out information, I'm not sure what I need to provide here. I've checked the pre-requisites and I believe I match them all. It all works fine on my solaris 2.6, 7 and 9 systems. Only Solaris 8 seems to be suffering at the moment. For good measure I have installed the latest recommended patch cluster from Sun but it has not made a difference. More of a problem is the failure occurs about 6.5 hours into the compile. Finally, I'm currently only working with sparc Solaris systems, I've not got access to any intel sparc systems to test this under solaris8/x86 Thanks Chris -- Summary: boostrap comparison failure (stage2?) during make bootstrap on solaris8 only? Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris dot pitchford at newsint dot co dot uk GCC build triplet: *-*-solaris2.8 GCC host triplet: *-*-solaris2.8 GCC target triplet: *-*-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26715
[Bug target/26695] -mabi=ieeelongdouble / undefined reference to _q_add.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 14:11 --- Not a GCC bug as explained by Joseph. -- 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=26695
[Bug bootstrap/26711] Compilation breaks in gcc/genattrtab.c on Mac OS X 10.2.8 on G4 with odcctools
--- Comment #3 from mtodorov at alu dot hr 2006-03-16 14:12 --- Subject: Re: Compilation breaks in gcc/genattrtab.c on Mac OS X 10.2.8 on G4 with odcctools Changing build_dir/gcc/auto-host.h #define HAVE_SYS_RESOURCE_H 1 makes build pass this point where it failed. This was set to #undef despite having the include in /usr/incude/sys/resource.h I guess configure script has not found it. I odn't have the knowledge of fixing the configure script, so it is a bootstrap bug after all. /* Define to 1 if you have the sys/resource.h header file. */ #ifndef USED_FOR_TARGET #define HAVE_SYS_RESOURCE_H 1 #endif The fact that it is created in bootstrap prevents me from chaning it in the beginning, so I have to wait till bootstrap fails miserably and then wix auto-host.h In case there is a problem with time for fixing this configure script, perhaps I can manage, but it will take me some time since I am not expert like you guys. Regards, Mirsad On Thu, 16 Mar 2006, pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 13:24 --- *** This bug has been marked as a duplicate of 13982 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711
[Bug tree-optimization/25985] [4.2 Regression] with optimization integer math fails
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-03-16 14:29 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01019.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg01019.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25985
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #4 from ccb at dl dot ac dot uk 2006-03-16 14:30 --- Created an attachment (id=11058) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11058action=view) fpu configuration file for mactel, uses apple supplied fenv.h For clearing this uses feclearexcept (FE_ALL_EXCEPT) For getting a pointer to the exception control fegetexceptflag(mode, FE_ALL_EXCEPT) is used. For setting individual flags fesetexceptflag (mode, FE_DENORMAL) is used. To use this file, some changes are required to configure.host, inparticular, host_cpu='i386' host_os='darwin8.5.1' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug fortran/26716] New: [4.1,4.2 regression] gfortran: incorrect choice of overloaded function
Compiling and running the code below with gfortran 4.1 or mainline produces the output foo1 foo2 foo2 instead of the correct output foo1 foo1 foo2 This occurs with 4.1 (release), 4.1.1 and mainline. 4.0.3 (prerelease) produces the correct output. module mod1 implicit none interface foo module procedure foo1, foo2 end interface contains subroutine foo1(bar) real bar print *,foo1 end subroutine subroutine foo2(bar) real bar(3) print *,foo2 end subroutine end module mod1 program blah use mod1 implicit none real bar(3) call foo (1e0) call foo (bar(1)) call foo (bar) end program -- Summary: [4.1,4.2 regression] gfortran: incorrect choice of overloaded function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26716
[Bug target/26713] Stack frame allocation limited to 32k
--- Comment #2 from christoph dot stueckjuergen at siemens dot com 2006-03-16 15:08 --- I tried 4.1.0. The assembly code looks slightly different, but the problem remains the same: main: 0: 27bd8010addiu sp,sp,-32752 4: ffbe7fe0sd s8,32736(sp) 8: 27bdffd0addiu sp,sp,-48 c: 03a0f02dmoves8,sp 10: 2402000cli v0,12 14: a3c2sb v0,0(s8) 18: 3c020001lui v0,0x1 1c: 005e1821adduv1,v0,s8 20: 24020022li v0,34 24: a0628001sb v0,-32767(v1) 28: 102dmovev0,zero 2c: 27dd0030addiu sp,s8,48 30: dfbe7fe0ld s8,32736(sp) 34: 27bd7ff0addiu sp,sp,32752 38: 03e8jr ra 3c: nop -- christoph dot stueckjuergen at siemens dot com changed: What|Removed |Added Version|3.4.3 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26713
[Bug fortran/26717] New: gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK,
Hi, compiling LAPACK with -O -ffast-math leads to an ICE in LAPACK's csptri.f and csytri.f: % gfortran -O -ffast-math -c csptri.f csptri.f: In function 'csptri': csptri.f:1: internal compiler error: in find_lattice_value, at tree-complex.c:133 The same error is encountered in the other file. Cheers, -ha -- Summary: gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK, Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
[Bug middle-end/26717] gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK,
--- Comment #1 from anlauf at gmx dot de 2006-03-16 15:45 --- Created an attachment (id=11059) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11059action=view) Original LAPACK source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
[Bug middle-end/26717] gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK,
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 15:59 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
FreeBSD 6.1-PRERELEASE /usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc/objc/objc-act.c:4910: internal compiler error: in extract_insn, at recog.c:2083
rusinante: gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 rusinante: rusinante: uname -a FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Fri Mar 10 16:53:41 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 root: cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/tmp/usr\ -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1obj/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1obj/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc/objc -I. -I/usr/obj/usr/src/tmp/legacy/usr/include -c objc-parse+DIKED.c /usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc/objc/objc-act.c: In function `generate_protocol_list': /usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc/objc/objc-act.c:4910: error: unrecognizable insn: (insn 15 13 16 0 (UnKnown Unknown) -1 (nil) (nil)) /usr/src/gnu/usr.bin/cc/cc1obj/../../../../contrib/gcc/objc/objc-act.c:4910: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Best regards, Valentin ChernoZemsky __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Bug middle-end/26717] [4.2 Regression] gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 16:21 ---
Reduced C testcase:
_Complex float f(_Complex float a, _Complex float b)
{
_Complex float c = a/a;
return c/ b;
}
--
The problem is that fold is folding a/a to 1.0 but not the complex version.
--
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-03-16 16:21:05
date||
Summary|gfortran: ICE at tree- |[4.2 Regression] gfortran:
|complex.c:133 with -O - |ICE at tree-complex.c:133
|ffast-math in LAPACK, |with -O -ffast-math in
||LAPACK,
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
[Bug bootstrap/26718] New: Bootstrap 4.1.0 fails on Apple Power G5
Building gcc V4.1.0 fails on an Apple Power G5 when building libstdc++. Environment Machine: Apple Power G5 (quad 2.5 Ghz), Mac OS X 10.4.4 uname -a output:- Darwin epx-paprika1.imp.univie.ac.at 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh powerpc System compiler: as supplied by apple. gcc -v output:- Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5247.obj~4/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5247) Build commands ../configure --prefix=/usr/local/gcc/4.1.0 --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++ make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap Output before build fails [...] /Users/andras/Public/ftp/source/gcc/gcc-4.1.0/objdir/./gcc/xgcc -shared-libgcc -B/Users/andras/Public/ftp/source/gcc/gcc-4.1.0/objdir/./gcc -nostdinc++ -L/Users/andras/Public/ftp/source/gcc/gcc-4.1.0/objdir/powerpc-apple-darwin8.4.0/libstdc++-v3/src -L/Users/andras/Public/ftp/source/gcc/gcc-4.1.0/objdir/powerpc-apple-darwin8.4.0/libstdc++-v3/src/.libs -B/usr/local/gcc/4.1.0/powerpc-apple-darwin8.4.0/bin/ -B/usr/local/gcc/4.1.0/powerpc-apple-darwin8.4.0/lib/ -isystem /usr/local/gcc/4.1.0/powerpc-apple-darwin8.4.0/include -isystem /usr/local/gcc/4.1.0/powerpc-apple-darwin8.4.0/sys-include -I/Users/andras/Public/ftp/source/gcc/gcc-4.1.0/objdir/powerpc-apple-darwin8.4.0/libstdc++-v3/include/powerpc-apple-darwin8.4.0 -I/Users/andras/Public/ftp/source/gcc/gcc-4.1.0/objdir/powerpc-apple-darwin8.4.0/libstdc++-v3/include -I/Users/andras/Public/ftp/source/gcc/gcc-4.1.0/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c c++locale.cc -o c++locale.o /dev/null 21 perl /Users/andras/Public/ftp/source/gcc/gcc-4.1.0/libstdc++-v3/scripts/make_exports.pl \ libstdc++-symbol.ver \ .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o \ `echo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la | \ sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ libstdc++-symbol.explist || (rm -f libstdc++-symbol.explist ; exit 1) nm -P .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a|nm: no name list nm error at /Users/andras/Public/ftp/source/gcc/gcc-4.1.0/libstdc++-v3/scripts/make_exports.pl line 130. make[5]: *** [libstdc++-symbol.explist] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: ***
[Bug middle-end/21781] real.c incorrectly values zero with a large exponent
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-16 16:34 --- Subject: Bug 21781 Author: sayle Date: Thu Mar 16 16:34:05 2006 New Revision: 112136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112136 Log: PR middle-end/21781 * real.c (real_from_string): If the mantissa is zero, don't bother parsing the exponent as the result should always be zero. * gcc.dg/real-const-1.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/real-const-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/real.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21781
[Bug libgcj/26706] [4.1/4.2] Unexpanded macro in libjava/classpath/configure
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-16 18:19 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-15 22:37:24 |2006-03-16 18:19:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26706
[Bug c/26719] New: Computed (integer) table changes with -O
System info: Debian Unstable, x86 (Transmeta Crusoe TM5800)
The following program produces different output when compiled with and without
optimisations. This didn't occur with gcc 4.0.3, it seems to be new with 4.1.0.
#include stdio.h
int table[32][256];
int main(void)
{
int i, j;
for (i = 0; i 32; i++)
for (j = 0; j 256; j++)
table[i][j] = ((signed char)j) * i;
for (i = 0; i 10; i++)
printf(%10i %10i\n, table[i][5], table[i][132]);
return 0;
}
Compiling without optimisations, the output is as desired. With -O1 the output
changes. Here's how I can reproduce the problem:
$ gcc-4.1 -o example.O0 example.c
$ gcc-4.1 -O1 -o example.O1 example.c
$ ./example.O0
0 0
5 -124
10 -248
15 -372
20 -496
25 -620
30 -744
35 -868
40 -992
45 -1116
$ ./example.O1
0 0
5132
10264
15396
20528
25660
30792
35924
40 1056
45 1188
$ gcc-4.1 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.0 (Debian 4.1.0-0)
--
Summary: Computed (integer) table changes with -O
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kmshanah at disenchant dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 18:24 --- Confirmed, ivopts is causing this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-03-16 18:24:54 date|| Summary|Computed (integer) table|[4.1/4.2 Regression] |changes with -O |Computed (integer) table ||changes with -O Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug middle-end/21781] real.c incorrectly values zero with a large exponent
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 18:27 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21781
[Bug bootstrap/26718] Bootstrap 4.1.0 fails on Apple Power G5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 18:29 --- This is interesting as this worked for me on powerpc-darwin7.9.0 just fine. Do you have a GNU binutils nm in your path? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26718
[Bug other/26715] boostrap comparison failure (stage2?)
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-16 18:31 --- Pretty weird indeed. What's the bootstrap compiler on the Solaris 8 machine? Is it the same as on the other machines? Could you try a C-only bootstrap with it and with another one? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING GCC build triplet|*-*-solaris2.8 |sparc-sun-solaris2.8 GCC host triplet|*-*-solaris2.8 |sparc-sun-solaris2.8 GCC target triplet|*-*-solaris2.8 |sparc-sun-solaris2.8 Summary|boostrap comparison failure |boostrap comparison failure |(stage2?) during make |(stage2?) |bootstrap on solaris8 only? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26715
[Bug ada/26678] GNAT BUG DETECTED when compiling AWS.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-16 18:33 --- Hmm, this source works for me just fine on powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
[Bug java/26720] New: Can't find method 'access$1(I)'
In the following test, gcj fails to generate an access method for the private
static members of type char, byte, and short, although it does generate the
access method for the private static members of type int and Object.
class AccessTest {
public interface Foo {
public void foo();
}
private static char buggy_char;
private static byte buggy_byte;
private static short buggy_short;
private static int i;
private static Object o;
static {
new Foo() {
public void foo() {
buggy_char = 0;
buggy_byte = 0;
buggy_short = 0;
i = 0;
o = null;
}
};
}
}
--
Summary: Can't find method 'access$1(I)'
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
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: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
[Bug target/25917] [4.0 Regression] gcc.c-torture/compile/20051228-1.c fails
--- Comment #7 from sje at gcc dot gnu dot org 2006-03-16 18:40 --- Subject: Bug 25917 Author: sje Date: Thu Mar 16 18:40:08 2006 New Revision: 112140 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112140 Log: PR target/25917 Backport from mainline. * config/ia64/predicates.md (extr_len_operand): New predicate. * config/ia64/ia64.md (extv): Tighten constraints. (extzv): Ditto. (*tbit_and_2): Ditto. (*tbit_and_3): Ditto. (*tbit_or_2): Ditto. (*tbit_or_3): Ditto. (*bit_zero): Ditto. (*bit_one): Ditto. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/ia64/ia64.md branches/gcc-4_1-branch/gcc/config/ia64/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25917
[Bug target/26721] New: [4.2 Regression]: Gcc generates unaligned access
With gcc version 4.2.0 20060316 (experimental) [trunk revision 112138 clean], I got lt-gcj-dbtool(10892): unaligned access to 0x6fff9d63, ip=0x217a02e0 lt-gcj-dbtool(10892): unaligned access to 0x6fff9d6b, ip=0x217a0301 lt-gcj-dbtool(10892): unaligned access to 0x6fff9d73, ip=0x217a0321 lt-gcj-dbtool(10892): unaligned access to 0x6fff9d7b, ip=0x217a0341 strncpy-chk.x1(16065): unaligned access to 0x6fff9201, ip=0x40001c00 strncpy-chk.x2(16153): unaligned access to 0x6fff9201, ip=0x40001ba1 strncpy-chk.x3(16260): unaligned access to 0x6fff9201, ip=0x40001f71 strncpy-chk.x4(16419): unaligned access to 0x6fff9201, ip=0x40001f50 PR9577(17600): unaligned access to 0x6fff8b03, ip=0x218c82e0 PR9577(17600): unaligned access to 0x6fff8b0b, ip=0x218c8301 PR9577(17600): unaligned access to 0x6fff8b13, ip=0x218c8321 PR9577(17600): unaligned access to 0x6fff8b1b, ip=0x218c8341 For example, /export/build/gnu/gcc/build-ia64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-ia64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strncpy-chk.c /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strncpy-chk-lib.c /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O2 -fno-show-column -lm -o /export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/strncpy-chk.x2 [EMAIL PROTECTED] gcc]$ ./strncpy-chk.x2 strncpy-chk.x2(23626): unaligned access to 0x6fffb611, ip=0x40001b81 [EMAIL PROTECTED] gcc]$ -- Summary: [4.2 Regression]: Gcc generates unaligned access Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/25917] [4.0 Regression] gcc.c-torture/compile/20051228-1.c fails
--- Comment #8 from sje at gcc dot gnu dot org 2006-03-16 18:42 --- Subject: Bug 25917 Author: sje Date: Thu Mar 16 18:42:18 2006 New Revision: 112141 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112141 Log: PR target/25917 Backport from mainline. * config/ia64/predicates.md (extr_len_operand): New predicate. * config/ia64/ia64.md (extv): Tighten constraints. (extzv): Ditto. (*tbit_and_2): Ditto. (*tbit_and_3): Ditto. (*tbit_or_2): Ditto. (*tbit_or_3): Ditto. (*bit_zero): Ditto. (*bit_one): Ditto. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/ia64/ia64.md branches/gcc-4_0-branch/gcc/config/ia64/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25917
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 18:42 --- self contained testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug bootstrap/26718] Bootstrap 4.1.0 fails on Apple Power G5
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26718
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-03-16 18:50 ---
This is a scev analysis problem; on code
D.2160_17 = (signed char) j_15;
D.2161_18 = (int) D.2160_17;
it says D.2161_18 = {0, +, 1}; however, since it wraps at 128 to -127, this is
not correct -- (int) {0, +, 1} (where the type of the chrec is char) would be.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
CC||sebastian dot pop at cri dot
||ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug target/25917] [4.0 Regression] gcc.c-torture/compile/20051228-1.c fails
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-16 18:50 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25917
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-03-16 18:51 ---
More precisely, the correct chrec would be
(int) (char) {0,+,1}
since we assume signed chrecs do not overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug bootstrap/26708] ppc-darwin bootstrap failure (gcc/libiberty/floatformat.c ?)
--- Comment #2 from perrin at msli dot com 2006-03-16 18:58 --- Thanks, those new tools worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26708
[Bug middle-end/26717] [4.2 Regression] gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK,
--- Comment #4 from kargl at gcc dot gnu dot org 2006-03-16 18:58 --- It looks like Andrew has found your problem. I will, however, suggest that you reconsider using --fast-math with gfortran. One of my codes works correctly without --fast-math, but it will generate NaN's with it. I have not tracked down the problem, nor have I files a bug report because the code is fairly large and complicated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #2 from hjl at lucon dot org 2006-03-16 18:58 --- The testcases are in gcc testsuites. I got tens of those. Pick one from lt-gcj-dbtool(10892): strncpy-chk.x1(16065): strncpy-chk.x2(16153): strncpy-chk.x3(16260): strncpy-chk.x4(16419): PR9577(17600): strncpy-chk.x2(23626): simple(1268): bytebuffer(2845): directbuffer(4306): findclass(5567): jniutf(6710): overload(7649): pr23739(8578): throwit(9569): ArrayStore.exe(10563): ArrayStore.exe(11775): ArrayStore2.exe(12943): Array_1.exe(14205): Array_2.exe(15497): Array_3.exe(16646): lt-gij(17680): CompareNaN.exe(18830): Divide_1.exe(19824): EvaluationOrder(20965): ExtraClassLoade(22160): ExtraClassLoade(22671): ExtraClassLoade(24410): FileHandleGcTes(25103): Final.exe(25774): Float_1.exe(26750): G19990301_01.ex(27669): G19990302_02.ex(28600): G19990303_01.ex(29565): G19990303_02.ex(30518): G19990304_01.ex(31505): G19990310_01.ex(32504): II.exe(883): InterfaceDispat(1433): InterfaceDispat(1891): InvokeInterface(2495): lt-gij(2868): Invoke_1.exe(3481): Invoke_2.exe(4204): KeepInline.exe(5078): LargeFile.exe(6022): MathBuiltin.exe(6974): Matrix4f.exe(7904): N19990310_02.ex(8902): N19990310_3.exe(9754): N19990310_4.exe(10670): N19990310_5.exe(11558): Overflow.exe(12477): PR12350.exe(13149): PR12416.exe(14016): PR12656_base.ex(14769): PR12915.exe(15332): PR12915.exe(16019): PR141.exe(24548): PR160.exe(25479): PR162.exe(26278): PR16867.exe(26883): lt-gij(27225): PR19870.exe(27799): PR19870_2.exe(28666): PR19921.exe(29313): PR20056.exe(30213): PR218.exe(31172): PR242.exe(32268): PR25535.exe(742): PR260.exe(1622): PR3096.exe(2540): PR3731.exe(3574): PR5057.exe(4557): PR5057_2.exe(5500): PR55.exe(6474): PR56.exe(7086): PR6085.exe(7670): PR6204.exe(8561): PR6729.exe(9564): PR6820.exe(10511): PR7482.exe(11535): Process_1.exe(12553): Process_2.exe(13582): Process_3.exe(14557): Process_4.exe(15582): Process_5.exe(16569): Process_6.exe(17592): Serialization.e(18525): Shazam.exe(19533): StaticConstruct(20513): StringBuffer_1.(21501): StringBuffer_ov(22495): String_overflow(23505): SyncGlobal.exe(24179): SyncTest.exe(24828): SyncTest.exe(25202): Synch.exe(25669): TLtest.exe(25998): TestProxy.exe(26363): Thread_Alive.ex(26878): Thread_HoldsLoc(27318): Thread_Interrup(27803): Thread_Join.exe(28187): lt-gij(28543): Thread_Monitor.(29000): Thread_Sleep.ex(29593): Thread_Wait.exe(29982): lt-gij(30315): Thread_Wait_2.e(30692): Thread_Wait_Int(31015): Throw_1.exe(31324): Throw_2.exe(31734): anfi.exe(32146): anon.exe(32571): anon2.exe(526): anon3.exe(947): anon4.exe(1371): anon_ctor_itf_a(1819): anonarray.exe(2245): anonarray2.exe(2659): anonarray3.exe(3110): assign.exe(3541): assign2.exe(3962): bclink.exe(4393): bytearray.exe(4800): gnu-11:pts/1[38] cat /tmp/x lt-gcj-dbtool(10892): strncpy-chk.x1(16065): strncpy-chk.x2(16153): strncpy-chk.x3(16260): strncpy-chk.x4(16419): PR9577(17600): strncpy-chk.x2(23626): simple(1268): bytebuffer(2845): directbuffer(4306): findclass(5567): jniutf(6710): overload(7649): pr23739(8578): throwit(9569): ArrayStore.exe(10563): ArrayStore.exe(11775): ArrayStore2.exe(12943): Array_1.exe(14205): Array_2.exe(15497): Array_3.exe(16646): lt-gij(17680): CompareNaN.exe(18830): Divide_1.exe(19824): EvaluationOrder(20965): ExtraClassLoade(22160): ExtraClassLoade(22671): ExtraClassLoade(24410): FileHandleGcTes(25103): Final.exe(25774): Float_1.exe(26750): G19990301_01.ex(27669): G19990302_02.ex(28600): G19990303_01.ex(29565): G19990303_02.ex(30518): G19990304_01.ex(31505): G19990310_01.ex(32504): II.exe(883): InterfaceDispat(1433): InterfaceDispat(1891): InvokeInterface(2495): lt-gij(2868): Invoke_1.exe(3481): Invoke_2.exe(4204): KeepInline.exe(5078): LargeFile.exe(6022): MathBuiltin.exe(6974): Matrix4f.exe(7904): N19990310_02.ex(8902): N19990310_3.exe(9754): N19990310_4.exe(10670): N19990310_5.exe(11558): Overflow.exe(12477): PR12350.exe(13149): PR12416.exe(14016): PR12656_base.ex(14769): PR12915.exe(15332): PR12915.exe(16019): PR141.exe(24548): PR160.exe(25479): PR162.exe(26278): PR16867.exe(26883): lt-gij(27225): PR19870.exe(27799): PR19870_2.exe(28666): PR19921.exe(29313): PR20056.exe(30213): PR218.exe(31172): PR242.exe(32268): PR25535.exe(742): PR260.exe(1622): PR3096.exe(2540): PR3731.exe(3574): PR5057.exe(4557): PR5057_2.exe(5500): PR55.exe(6474): PR56.exe(7086): PR6085.exe(7670): PR6204.exe(8561): PR6729.exe(9564): PR6820.exe(10511): PR7482.exe(11535): Process_1.exe(12553): Process_2.exe(13582): Process_3.exe(14557): Process_4.exe(15582): Process_5.exe(16569): Process_6.exe(17592): Serialization.e(18525): Shazam.exe(19533): StaticConstruct(20513): StringBuffer_1.(21501): StringBuffer_ov(22495): String_overflow(23505): SyncGlobal.exe(24179): SyncTest.exe(24828): SyncTest.exe(25202): Synch.exe(25669): TLtest.exe(25998): TestProxy.exe(26363): Thread_Alive.ex(26878): Thread_HoldsLoc(27318): Thread_Interrup(27803): Thread_Join.exe(28187): lt-gij(28543): Thread_Monitor.(29000): Thread_Sleep.ex(29593): Thread_Wait.exe(29982):
[Bug c/26722] New: ICE in extract_insn, at recog.c:2175
Hardware: Xeon 3.2 GHz dual-core OS: Linux Debian sarge 2.6.14.3-grsec #1 SMP Attachment with .i follows. gcc -O2 -W -march=pentium3 -mmmx -msse -msse2 -I../libjbig -c -o jbig.o jbig.c jbig.c: In function `encode_sde': jbig.c:1474: error: unrecognizable insn: (insn:HI 3480 3479 3127 20 0x2d245a5172a0 (set (reg/v:SI 91) (plus:SI (mult:SI (reg/v:SI 91) (const_int 2 [0x2])) (const_int 3 [0x3]))) -1 (insn_list 3479 (nil)) (nil)) jbig.c:1474: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.3/README.Bugs. make[1]: *** [jbig.o] Error 1 make[1]: Leaving directory `/home/osob/mtodorov/jbigkit/libjbig' make: *** [lib] Error 2 [EMAIL PROTECTED]:~/jbigkit$ -- Summary: ICE in extract_insn, at recog.c:2175 Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtodorov at alu dot hr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
[Bug c/26722] ICE in extract_insn, at recog.c:2175
--- Comment #1 from mtodorov at alu dot hr 2006-03-16 19:05 --- Created an attachment (id=11060) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11060action=view) The jbig.i file that causes ICE This is a part of jbigkit.tar.gz library for JBIG pictures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
[Bug target/26722] ICE in extract_insn, at recog.c:2175
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
[Bug libgcj/26706] [4.1/4.2] Unexpanded macro in libjava/classpath/configure
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-16 19:08 --- Subject: Bug 26706 Author: tromey Date: Thu Mar 16 19:08:07 2006 New Revision: 112142 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112142 Log: PR libgcj/26706: * aclocal.m4, configure: Rebuilt. * configure.ac (GCC_NO_EXECUTABLES): Moved earlier. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/aclocal.m4 trunk/libjava/classpath/configure trunk/libjava/classpath/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26706
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #3 from hjl at lucon dot org 2006-03-16 19:08 --- It may be related to http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00999.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00997.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html Maxim, can you verify that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26722] ICE in extract_insn, at recog.c:2175
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 19:09 --- Can you give output of gcc -v? This works just fine with FSF's GCC 3.3.3 and 3.4.0 and 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
[Bug libgcj/26706] [4.1/4.2] Unexpanded macro in libjava/classpath/configure
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-16 19:12 --- Subject: Bug 26706 Author: tromey Date: Thu Mar 16 19:12:29 2006 New Revision: 112143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112143 Log: PR libgcj/26706: * aclocal.m4, configure: Rebuilt. * configure.ac (GCC_NO_EXECUTABLES): Moved earlier. Modified: branches/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj branches/gcc-4_1-branch/libjava/classpath/aclocal.m4 branches/gcc-4_1-branch/libjava/classpath/configure branches/gcc-4_1-branch/libjava/classpath/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26706
[Bug libgcj/26706] [4.1/4.2] Unexpanded macro in libjava/classpath/configure
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-16 19:15 --- I checked in the fix. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26706
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #4 from hjl at lucon dot org 2006-03-16 19:17 --- BTW, I saw it on RHEL 4 U3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug middle-end/18259] -fdump-tree-tu omits real constant values
--- Comment #3 from sayle at gcc dot gnu dot org 2006-03-16 19:47 --- Subject: Bug 18259 Author: sayle Date: Thu Mar 16 19:47:19 2006 New Revision: 112147 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112147 Log: 2006-03-16 Roger Sayle [EMAIL PROTECTED] Daniel Speyer [EMAIL PROTECTED] PR middle-end/18259 * tree-dump.c (dump_real): New function. (dequeue_and_dump) REAL_CST: Use it to dump FP constants. * Makefile.in (REAL_H): New macro for dependencies on real.h. (tree-dump.o): Add $(REAL_H) to the dependencies. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/tree-dump.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18259
[Bug middle-end/18259] -fdump-tree-tu omits real constant values
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 20:18 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18259
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-03-16 20:32 --- (In reply to comment #3) It may be related to http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00999.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00997.html http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html Maxim, can you verify that? I've tested the mainline r18717 (the one just before my patches) on the strncpy-chk.x2 test and it reported the same unalligned access. The unalligned access itself is due to store of a char as an int: ;; (insn 170 ...) add r38 = r12, 17 ;; r12 is a stack pointer. ... ;; (insn 172 ...) st4 [r38] = r37 ;; unalligned store. I don't know which pass is responsible to eliminate unalligned references, but it seems to me that that pass skips this one case. BTW, the very first rtl dump .expand has the same instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug c++/26723] New: invocation order of functions registered with atexit() not as expected
Almost verbatim from the standard:
/// 1. Objects with static storage duration are destroyed
///and functions registered by calling atexit are
///called. Objects with static storage duration are
///destroyed in the reverse order of the completion
///of their constructor.
/// 2. Functions registered with atexit are called in the
///reverse order of their registration. A function
///registered with atexit before an object obj1 of static
///storage duration is initialized will not be called until
///obj1s destruction has completed. A function registered
///with atexit after an object obj2 of static storage
///duration is initialized will be called before obj2
///destruction starts.
#include iostream
static void pre_exit(void) {
std::cout @pre_exit std::endl;
}
static void post_exit(void) {
std::cout @post_exit std::endl;
}
struct FIRST {
FIRST() {
atexit(pre_exit);
std::cout FIRST::FIRST() std::endl;
}
~FIRST() {
std::cout FIRST::~FIRST() std::endl;
}
};
struct SECOND {
SECOND() { std::cout SECOND::SECOND() std::endl; }
~SECOND() { std::cout SECOND::~SECOND() std::endl; }
};
static FIRST_first;
static SECOND _second;
///
int main() {
if (atexit(post_exit)) { /* registration failed */ }
std::cout whatever std::endl;
std::cout.flush();
return 0;
}
/ the output is:
FIRST::FIRST()
SECOND::SECOND()
whatever
@post_exit
@pre_exit
SECOND::~SECOND()
FIRST::~FIRST()
/// where I would expect it to be:
FIRST::FIRST()
SECOND::SECOND()
whatever
@post_exit
SECOND::~SECOND()
@pre_exit
FIRST::~FIRST()
/// or maybe even
FIRST::FIRST()
SECOND::SECOND()
whatever
@post_exit
SECOND::~SECOND()
FIRST::~FIRST() // pre_exit was registered before FIRST() completed.
@pre_exit
--
Summary: invocation order of functions registered with atexit()
not as expected
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan at sierra-da dot com
GCC build triplet: linux/i686/rh9
GCC host triplet: linux/i686/rh9
GCC target triplet: linux/i686/rh9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26723
[Bug target/26722] ICE in extract_insn, at recog.c:2175
--- Comment #3 from mtodorov at alu dot hr 2006-03-16 21:05 --- Subject: Re: ICE in extract_insn, at recog.c:2175 Of course, I should have done it in the first place: [EMAIL PROTECTED]:~/jbigkit/libjbig$ gcc -v Reading specs from /usr/lib/gcc-lib/x86_64-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc --disable-multilib x86_64-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) [EMAIL PROTECTED]:~/jbigkit/libjbig$ Mirsad On Thu, 16 Mar 2006, pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 19:09 --- Can you give output of gcc -v? This works just fine with FSF's GCC 3.3.3 and 3.4.0 and 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
[Bug c++/26723] invocation order of functions registered with atexit() not as expected
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 21:28 --- Can you give the output of gcc -v? This is the output I get: FIRST::FIRST() SECOND::SECOND() whatever @post_exit SECOND::~SECOND() FIRST::~FIRST() @pre_exit --enable-__cxa_atexit is required to get this behavior, otherwise you get the wrong behvaior due to deconstructors running at the wrong time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26723
[Bug fortran/26716] [4.1,4.2 regression] gfortran: incorrect choice of overloaded function
--- Comment #1 from pault at gcc dot gnu dot org 2006-03-16 21:31 --- Yes indeed. It occurs for 4.1 and 4.2 but NOT for 4.0. I have put this to severity major because we must get interfaces right. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-16 21:31:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26716
too few template-parameter-lists with nested template
I've seen other posts asking a similar question, but the solution continues to
evade me.
I have a line of code that compiles and runs as designed with MSVC but not
under g++ 3.4.2 (mingw-special):
HashTableFactoryAbstractProductUnitTest::FactoryEntry
FactoryAbstractProductUnitTest::sFactoryTable ;
The following lines do compile (but see caveat below):
template class EntryT class
HashTableFactoryAbstractProductUnitTest::FactoryEntry
FactoryAbstractProductUnitTest::sFactoryTable ;
...or...
template class HashTableFactoryAbstractProductUnitTest::FactoryEntry
FactoryAbstractProductUnitTest::sFactoryTable ;
The resulting code, however, seems not to have called the constructor on
sFactoryTable by the time it gets used, which is well after main starts -
i.e. this is not a problem with order of execution of static constructors.
Here is some context for the code above:
template class EntryT class HashTable
{
...
protected:
LinkedListEntryT * mLists ;
...
} ;
template class AbstractProductT class Factory : public HashEntry
{
...
protected:
struct FactoryEntry : public HashEntry
{ // struct to associate a factory with a hash table key.
FactoryAbstractProductT * mFactory ;
} ;
static HashTableFactoryEntry sFactoryTable ; // singleton list of
concrete factories associated with this abstract factory
} ;
I searched http://gcc.gnu.org/ and found several simpler variations where
people complained about initialization of static templated class members, the
solution to which was to prefix the class name with template , but I found
no mention of a situation like that above, which involves nested templated
classes.
I apologize if this reflects my ignorance rather than a bug in the GNU C
compiler, and would appreciate having somebody explain how to make this work.
Thanks.
Michael J. Gourlay
[Bug middle-end/26379] [4.0 Regression] ICE on vector shift RTL simplification
--- Comment #6 from sayle at gcc dot gnu dot org 2006-03-16 21:33 --- Subject: Bug 26379 Author: sayle Date: Thu Mar 16 21:33:38 2006 New Revision: 112152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112152 Log: PR middle-end/26379 Backport from mainline. 2006-02-21 Jakub Jelinek [EMAIL PROTECTED] * combine.c (simplify_shift_const_1): Disable nested shifts optimization for vector shifts. * gcc.target/i386/mmx-7.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.target/i386/mmx-7.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/combine.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26379
[Bug bootstrap/26718] Bootstrap 4.1.0 fails on Apple Power G5
--- Comment #2 from fang at csl dot cornell dot edu 2006-03-16 21:39 --- Looks like my problem from PR 26385, but I was trying to use odcctools' nm. Is GNU binutils' nm also suitable? -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26718
[Bug target/24838] g++.dg/tls/static-1.C execution test fails
--- Comment #2 from sje at cup dot hp dot com 2006-03-16 21:45 --- I am resolving this bug as fixed with the same resolution as PR 24476, since the change I made for PR 24476 also fixes this failure. See PR 24476 for more information on the problem fix. Basically, you have to use the latest (after 2.16) binutils to fix this problem. -- sje at cup dot hp dot com changed: What|Removed |Added BugsThisDependsOn||24476 Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Bug 24838 depends on bug 24476, which changed state. Bug 24476 Summary: [4.1/4.2 Regression] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24476 What|Old Value |New Value Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24838
[Bug fortran/26716] [4.1,4.2 regression] gfortran: incorrect choice of overloaded function
--- Comment #2 from pault at gcc dot gnu dot org 2006-03-16 21:53 --- Annoyingly, the bug has been introduced by one of my patches: http://gcc.gnu.org/ml/fortran/2006-01/msg00424.html It was the bit for PR25070. I'll see what I can do. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-03-16 21:31:33 |2006-03-16 21:53:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26716
[Bug bootstrap/26718] Bootstrap 4.1.0 fails on Apple Power G5
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 21:54 --- (In reply to comment #2) Looks like my problem from PR 26385, but I was trying to use odcctools' nm. Is GNU binutils' nm also suitable? I have never used the GNU binutils or even odcctools nm which is why I asked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26718
[Bug c++/26723] invocation order of functions registered with atexit() not as expected
--- Comment #2 from ivan at sierra-da dot com 2006-03-16 21:56 --- gcc -v: Reading specs from /project/tools/linux_i686_2.3.2-2005-08-31-17.44.37/stow/gcc-3.3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs Configured with: XXX/gcc-3.3.3/configure --prefix=XXXgcc-3.3.3 --with-local-prefix=XXX --enable-languages=c,c++ --with-libiconv-prefix=XXX/gcc-3.3.3 --with-gnu-ld --with-ld=XXX/bin/ld --with-gnu-as --with-as=XXX/bin/as Thread model: posix gcc version 3.3.3 also --- g++ --enable-__cxa_atexit ...: cc1plus: error: unrecognized option `-fenable-__cxa_atexit' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26723
[Bug c++/26723] invocation order of functions registered with atexit() not as expected
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 22:00 --- (In reply to comment #2) gcc -v: Configured with: XXX/gcc-3.3.3/configure --prefix=XXXgcc-3.3.3 --with-local-prefix=XXX --enable-languages=c,c++ --with-libiconv-prefix=XXX/gcc-3.3.3 --with-gnu-ld --with-ld=XXX/bin/ld --with-gnu-as --with-as=XXX/bin/as g++ --enable-__cxa_atexit ...: cc1plus: error: unrecognized option `-fenable-__cxa_atexit' at configure time I mean. And that is your issue -- 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=26723
[Bug target/26189] Bug in vendor /usr/include/net/if.h needs fixincluding on HPUX
--- Comment #5 from sje at gcc dot gnu dot org 2006-03-16 22:02 --- Subject: Bug 26189 Author: sje Date: Thu Mar 16 22:02:43 2006 New Revision: 112154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112154 Log: PR target/26189 Backport from mainline. * inclhack.def (hpux_spu_info): New. * fixincl.x: Regenerate Modified: branches/gcc-4_0-branch/fixincludes/ChangeLog branches/gcc-4_0-branch/fixincludes/fixincl.x branches/gcc-4_0-branch/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189
[Bug target/26189] Bug in vendor /usr/include/net/if.h needs fixincluding on HPUX
--- Comment #6 from sje at cup dot hp dot com 2006-03-16 22:03 --- Fixed on 4.0 line for 4.0.4, 4.1 line for 4.1.1 and on ToT for 4.2. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189
[Bug libstdc++/25482] Specialize (overload) std::copy/find for streambuf iterators
--- Comment #1 from pcarlini at suse dot de 2006-03-16 22:17 --- Working on it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-16 22:17:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25482
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #6 from sje at cup dot hp dot com 2006-03-16 22:25 ---
Here is a cut down test case, I guess GCC is trying to map the strncpy into an
integer move without taking alignment into account.
extern char *strncpy (char *, const char *, __SIZE_TYPE__);
int main()
{
const char *const foo = hello world;
char dst [64];
strncpy (dst + 1, foo + 1, 4);
return 0;
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-03-16 22:25:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #7 from sje at cup dot hp dot com 2006-03-16 23:06 --- It looks to me like this is due to Richard Guenther's patch at: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html When I removed the non-structure part of this patch the problem went away. specifically I changed align = MIN (inner, DECL_ALIGN (exp)); back to align = MIN (align, DECL_ALIGN (exp)); for the DECL_P case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-16 23:09 --- (In reply to comment #7) It looks to me like this is due to Richard Guenther's patch at: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html When I removed the non-structure part of this patch the problem went away. specifically I changed If you do that you will cause a real testcase failure on powerpc-*. Now does this really show up as failure or is IA64 target for GNU/Linux does not set strict alignment? If GCC for ia64-linux-gnu does not set STRICT alignment, then is not the bug but instead a bug somewhere else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-16 23:10 --- Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by default? Yes it is slower but there is setting for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-16 23:13 --- (In reply to comment #6) Here is a cut down test case, I guess GCC is trying to map the strncpy into an integer move without taking alignment into account. This is all dead code, this testcase does nothing for me on PPC-darwin, it just returns 0. _main: li r3,0 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #11 from sje at cup dot hp dot com 2006-03-16 23:16 --- I compiled the test case at -O1 on IA64 HP-UX to get the bus error due to the unaligned access. IA64 HP-UX does require STRICT_ALIGNMENT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #12 from schwab at suse dot de 2006-03-16 23:37 --- (In reply to comment #9) Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by default? prctl --unaligned=signal will make it generate bus errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
Re: [Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote: --- Comment #12 from schwab at suse dot de 2006-03-16 23:37 --- (In reply to comment #9) Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by default? prctl --unaligned=signal will make it generate bus errors. But that is a different issue and really this should be handled correctly in that since the target supported by default the unaligned handlers, it should not set STRICT_ALIGNMENT to 1. Now the target can have an option to turn it on, witness PPC-elf/PPC-linux which has one as some embedded hardware/OS's don't support the unalignement trap. -- Pinski
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-16 23:54 --- Subject: Re: [4.2 Regression]: Gcc generates unaligned access On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote: --- Comment #12 from schwab at suse dot de 2006-03-16 23:37 --- (In reply to comment #9) Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by default? prctl --unaligned=signal will make it generate bus errors. But that is a different issue and really this should be handled correctly in that since the target supported by default the unaligned handlers, it should not set STRICT_ALIGNMENT to 1. Now the target can have an option to turn it on, witness PPC-elf/PPC-linux which has one as some embedded hardware/OS's don't support the unalignement trap. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug middle-end/26379] [4.0 Regression] ICE on vector shift RTL simplification
--- Comment #7 from roger at eyesopen dot com 2006-03-17 00:17 --- I've now committed this patch (as approved by Mark) to the 4.0 branch for Jakub, so this PR can be closed. -- roger at eyesopen dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26379
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-03-17 00:22
---
Now ia64-hpux is a different story.
Maybe the real question is why DSE/DCE is not deleting the dead code which it
is?
But for future reference the docs for STRICT_ALIGNMENT is:
@defmac STRICT_ALIGNMENT
Define this macro to be the value 1 if instructions will fail to work
if given data not on the nominal alignment. If instructions will merely
go slower in that case, define this macro as 0.
@end defmac
Which means by default on ia64-linux-gnu, it should be defined to 1 and then
SLOW_UNALIGNED_ACCESS should return 1.
The docs for that:
@defmac SLOW_UNALIGNED_ACCESS (@var{mode}, @var{alignment})
Define this macro to be the value 1 if memory accesses described by the
@var{mode} and @var{alignment} parameters have a cost many times greater
than aligned accesses, for example if they are emulated in a trap
handler.
When this macro is nonzero, the compiler will act as if
@code{STRICT_ALIGNMENT} were nonzero when generating code for block
moves. This can cause significantly more instructions to be produced.
Therefore, do not set this macro nonzero if unaligned accesses only add a
cycle or two to the time for a memory access.
If the value of this macro is always zero, it need not be defined. If
this macro is defined, it should produce a nonzero value when
@code{STRICT_ALIGNMENT} is nonzero.
@end defmac
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #15 from schwab at suse dot de 2006-03-17 00:37 --- Both alpha and sparc can emulate unaligned accesses, and both set STRICT_ALIGNMENT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
Re: [Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote: --- Comment #15 from schwab at suse dot de 2006-03-17 00:37 --- Both alpha and sparc can emulate unaligned accesses, and both set STRICT_ALIGNMENT. And PPC can emulate unalgined access (and does by default) and it sets STRICT_ALIGNMENT to 0. Lets define it correctly for new targets if they implement unaligned access in software. -- Pinski
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-17 00:40 --- Subject: Re: [4.2 Regression]: Gcc generates unaligned access On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote: --- Comment #15 from schwab at suse dot de 2006-03-17 00:37 --- Both alpha and sparc can emulate unaligned accesses, and both set STRICT_ALIGNMENT. And PPC can emulate unalgined access (and does by default) and it sets STRICT_ALIGNMENT to 0. Lets define it correctly for new targets if they implement unaligned access in software. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26722] ICE in extract_insn, at recog.c:2175
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 01:03 --- This works for me in 3.3.3 and 3.3.6 so closing as works for me. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #17 from schwab at suse dot de 2006-03-17 01:06 --- PPC does not trap on unaligned integer load and store. Neither ia64 nor alpha nor sparc can do unaligned load and store in hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
