[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From uros at kss-loka dot si 2005-01-19 08:17 --- This functionality is missing after FP compares rewrite: ==i386_old.md== ... ;; We can't represent the LT test directly. Do this by swapping the operands. (define_split [(set (match_operand:SF 0 "fp_register_operand" "") (if_then_else:SF (lt (match_operand:SF 1 "register_operand" "") (match_operand:SF 2 "register_operand" "")) (match_operand:SF 3 "register_operand" "") (match_operand:SF 4 "register_operand" ""))) (clobber (reg:CC 17))] "reload_completed && ((operands_match_p (operands[1], operands[3]) && operands_match_p (operands[2], operands[4])) || (operands_match_p (operands[1], operands[4]) && operands_match_p (operands[2], operands[3])))" [(set (reg:CCFP 17) (compare:CCFP (match_dup 2) (match_dup 1))) (set (match_dup 0) (if_then_else:SF (ge (reg:CCFP 17) (const_int 0)) (match_dup 1) (match_dup 2)))]) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug libfortran/19524] New: 5 times uninitialized var in libgfortran
during bootstrap the compiler warns: ../../../libgfortran/generated/matmul_l4.c:102: warning: 'astride' is used uninitialized in this function ../../../libgfortran/generated/matmul_l4.c:109: warning: 'bstride' is used uninitialized in this function ../../../libgfortran/generated/matmul_l8.c:102: warning: 'astride' is used uninitialized in this function ../../../libgfortran/generated/matmul_l8.c:109: warning: 'bstride' is used uninitialized in this function ../../../libgfortran/io/read.c:603: warning: 'buffer' is used uninitialized in this function and yes, astride and bstride are used uninitialized in those 2 files, and buffer can be used undefined too. -- Summary: 5 times uninitialized var in libgfortran Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de CC: gcc-bugs at gcc dot gnu dot org 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=19524
[Bug other/19525] New: [4.0 Regression] In-build-tree multilib testing broken
The new flat layout of the multilibed libgcc_s shared library in the build tree has broken in-tree multilib testing on IRIX and Solaris because there are now multiple shared objects with the same soname in the same directory. Richard Sandiford's analysis for IRIX and plausible kludge: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00437.html The same analysis holds for SPARC/Solaris with the 32-bit compiler: lrwxrwxrwx 13 Jan 19 01:13 libgcc_s.so -> libgcc_s.so.1 -rwxrwxr-x 138743 Jan 19 01:13 libgcc_s.so.1 -rwxrwxr-x 138743 Jan 19 01:12 libgcc_s.so.1.backup lrwxrwxrwx 13 Jan 19 01:13 libgcc_s_sparcv9.so -> libgcc_s_sparcv9.so.1 -rwxrwxr-x 196553 Jan 19 01:13 libgcc_s_sparcv9.so.1 -rwxrwxr-x 196553 Jan 19 01:12 libgcc_s_sparcv9.so.1.backup and the 64-bit compiler: lrwxrwxrwx 13 Jan 19 01:10 libgcc_s.so -> libgcc_s.so.1 -rwxrwxr-x 262624 Jan 19 01:10 libgcc_s.so.1 -rwxrwxr-x 262624 Jan 19 01:09 libgcc_s.so.1.backup lrwxrwxrwx 21 Jan 19 01:10 libgcc_s_sparcv7.so -> libgcc_s_sparcv7.so.1 -rwxrwxr-x 191368 Jan 19 01:10 libgcc_s_sparcv7.so.1 -rwxrwxr-x 191368 Jan 19 01:10 libgcc_s_sparcv7.so.1.backup -- Summary: [4.0 Regression] In-build-tree multilib testing broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: *-*-irix* *-*-solaris* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
[Bug ada/19526] New: Windows errorcodes wrong in Ada when tasking
BUG REPORTS HAVE TO CONTAIN AT LEAST THE FOLLOWING INFORMATION IN ORDER TO BE
USEFUL:
the exact version of GCC, as shown by "gcc -v";
gcc -v
Reading specs from C:/languages/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --
host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --
enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-
shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x -
-enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-
synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
THE SYSTEM TYPE;
Windows 2000 Professional, Windows 2000 Server, Windows 2003
THE OPTIONS WHEN GCC WAS CONFIGURED/BUILT;
Binaries used from minGW containing
MinGW version 3.2.0 contains the following list of packages:
gcc-ada-3.4.2.tar.gz
gcc-core-3.4.2.tar.gz
gcc-g++-3.4.2.tar.gz
gcc-g77-3.4.2.tar.gz
gcc-java-3.4.2.tar.gz
gcc-objc-3.4.2.tar.gz
binutils-2.15.91-20040904-1
mingw-runtime-3.6
w32api-3.2
gdb-5.2.1-1
mingw32-make-3.80.0-3
mingw-utils-0.3.tar.gz
But this bug also applies to the 'official' gnat 3.15p from ACT
THE EXACT COMMAND LINE PASSED TO THE GCC PROGRAM TRIGGERING THE BUG
(not just the flags passed to gnatmake, but gnatmake prints the parameters it
passed to gcc)
C:\Temp>gnatmake socket_connect.adb
gcc -c socket_connect.adb
socket_connect.adb:3:18: warning: "Gnat.Sockets.Thin" is an internal GNAT unit
socket_connect.adb:3:18: warning: use of this unit is non-portable and
version-d
ependent
gnatbind -x socket_connect.ali
gnatlink socket_connect.ali
A COLLECTION OF SOURCE FILES FOR REPRODUCING THE BUG, PREFERABLY A MINIMAL SET
(SEE BELOW);
with Text_Io;
with Gnat.Sockets;
with Gnat.Sockets.Thin;
with Ada.Exceptions;
procedure Socket_Connect is
Socket : Gnat.Sockets.Socket_Type;
Address : Gnat.Sockets.Sock_Addr_Type;
Error: Integer := 0;
--
task type Run_Once is
entry Execute;
end Run_Once;
--
task body Run_Once is
begin
select
accept Execute do
text_io.put_line("Task running, Execute!");
end Execute;
or
terminate;
end select;
end Run_Once;
--
begin
declare
TmpTask : Run_Once;
begin
TmpTask.Execute;
end;
text_io.put_line("Startup sockets");
Gnat.Sockets.Initialize;
text_io.put_line("Get a socket");
Gnat.Sockets.Create_Socket (Socket);
text_io.put_line("Try to connect!");
Address.Addr := Gnat.Sockets.Inet_Addr("127.0.0.1");
Address.Port := 8000;
Gnat.Sockets.Connect_Socket (Socket, Address);
text_io.put_line("Connected!");
text_io.put_line("Close socket!");
Gnat.Sockets.Close_Socket (Socket);
text_io.put_line("Shutdown sockets!");
Gnat.Sockets.Finalize;
text_io.put_line("Done!");
exception
when E: others =>
Text_IO.Put_Line(Ada.Exceptions.Exception_Name (E) & ": " &
Ada.Exceptions.Exception_Message (E));
Error := Gnat.Sockets.Thin.Socket_Errno;
Text_IO.Put_Line(Integer'Image(Error) & " - " ) ; --&
--Gnat.Sockets.Thin.Socket_Error_Message (Error));
Text_IO.Put_Line("Resolve_Exception" & " - " &
Gnat.Sockets.Error_Type'Image(Gnat.Sockets.Resolve_Exception(E)));
Gnat.Sockets.Finalize;
end Socket_Connect;
A DESCRIPTION OF THE EXPECTED BEHAVIOR;
I'd like an output like this:
C:\Temp>socket_connect
Task running, Execute!
Startup sockets
Get a socket
Try to connect!
GNAT.SOCKETS.SOCKET_ERROR: [10061] Connection refused
10061 -
Resolve_Exception - CONNECTION_REFUSED
Note the second last line, printed by a call to
Gnat.Sockets.Thin.Socket_Errno.
I get the behavior when I comment out the task type.
(well not the 'Task running, Execute' of course)
A DESCRIPTION OF ACTUAL BEHAVIOR.
C:\Temp>socket_connect
Task running, Execute!
Startup sockets
Get a socket
Try to connect!
GNAT.SOCKETS.SOCKET_ERROR: [10061] Connection refused
0 -
Resolve_Exception - CONNECTION_REFUSED
Note the second last line, printed by a call to
Gnat.Sockets.Thin.Socket_Errno.
This time there's no error!
This behavior occurs when any task at all is involved. If I write my
own socket biding, and call WSAGetLastError
(as Gnat.Sockets.Thin.Socket_Errno does)
I still have this behavior. So I can recognize a socketerror,
via the fact that c-socket function return -1 on error but
NOT find the reason, unless I use Gnat.sockets, and mask the error out from
the exception, which breaks socket code not written unsing Gn
[Bug other/19525] [4.0 Regression] In-build-tree multilib testing broken
-- What|Removed |Added CC||rsandifo at redhat dot com, ||zack at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pcarlini at suse dot de 2005-01-19 09:09 --- > Does this behaviour seem a little bit unusual to you? You said: "You > cannot create a basic_string object in memory aligned one". > That is rather counter-intuitive to a user of libstdc++ who has no > understanding of the implementation details of basic_string. I don't think so. Memory provided by new, f.i., is never returned aligned one. Quite to the contrary, *missing* a knowledge of the internal impl details, you are supposed to pass to the string object an allocator returning memory maximally aligned (like the default one does!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From stevenb at novell dot com 2005-01-19 09:12 --- Subject: Re: DSE is not doing its job for global variables Do you happen to have numbers on how many dead stores the RTL dead store elimination (in flow.c, right) catches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug middle-end/19164] [3.3/3.4/4.0 Regression] ICE in digest_init or build_vector
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 09:27 --- Subject: Bug 19164 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-19 09:27:24 Modified files: gcc: ChangeLog c-typeck.c gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050113-1.c gcc/testsuite/gcc.dg: 20050113-1.c Log message: PR c/17297 * c-typeck.c (digest_init): Only call build_vector if all constructor elements are *_CST nodes. * gimplify.c (gimplify_init_constructor): Likewise. * gcc.c-torture/compile/20050113-1.c: New testcase. PR middle-end/19164 * c-typeck.c (digest_init): Only call build_vector if inside_init is a CONSTRUCTOR. * gcc.dg/20050113-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7183&r2=2.7184 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.410&r2=1.411 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.103&r2=2.104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4907&r2=1.4908 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050113-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050113-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19164
[Bug c/17297] [3.4/4.0 Regression] ICE with FP vector constructor containing qnan calculation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 09:27 --- Subject: Bug 17297 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-19 09:27:24 Modified files: gcc: ChangeLog c-typeck.c gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050113-1.c gcc/testsuite/gcc.dg: 20050113-1.c Log message: PR c/17297 * c-typeck.c (digest_init): Only call build_vector if all constructor elements are *_CST nodes. * gimplify.c (gimplify_init_constructor): Likewise. * gcc.c-torture/compile/20050113-1.c: New testcase. PR middle-end/19164 * c-typeck.c (digest_init): Only call build_vector if inside_init is a CONSTRUCTOR. * gcc.dg/20050113-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7183&r2=2.7184 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.410&r2=1.411 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.103&r2=2.104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4907&r2=1.4908 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050113-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050113-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17297
[Bug rtl-optimization/15139] [3.4 Regression] cc1 uses excessive amounts of memory compiling small routine
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 09:31 --- Subject: Bug 15139 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-19 09:31:16 Modified files: gcc: ChangeLog Makefile.in combine.c params.def params.h gcc/doc: invoke.texi gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050111-2.c Log message: PR rtl-optimization/15139 * combine.c: Include params.h. (count_rtxs): New function. (record_value_for_reg): If replace_rtx would replace at least 2 occurrences of REG in VALUE and TEM is really large, replace REG with (clobber (const_int 0)) instead of TEM. * params.def (PARAM_MAX_LAST_VALUE_RTL): New. * params.h (MAX_LAST_VALUE_RTL): New. * Makefile.in (combine.o): Depend on $(PARAMS_H). * doc/invoke.texi (--param max-last-value-rtl=N): Document. * gcc.dg/20050111-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7184&r2=2.7185 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1442&r2=1.1443 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&r1=1.468&r2=1.469 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gcc&r1=1.51&r2=1.52 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.h.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.568&r2=1.569 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4908&r2=1.4909 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050111-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15139
[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-19 09:34 --- Reopening PR, as the report supposedly referred to in comment #9 was with native tools (/usr/ccs/bin something). I hope to close this PR in a day or two pending a bootstrap with gas+ld. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
[Bug c/17297] [3.4/4.0 Regression] ICE with FP vector constructor containing qnan calculation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 09:45 --- Subject: Bug 17297 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-19 09:44:49 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050113-1.c gcc/testsuite/gcc.dg: 20050113-1.c Log message: PR c/17297 * c-typeck.c (digest_init): Only call build_vector if all constructor elements are *_CST nodes. * gcc.c-torture/compile/20050113-1.c: New testcase. PR middle-end/19164 * c-typeck.c (digest_init): Only call build_vector if inside_init is a CONSTRUCTOR. * gcc.dg/20050113-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.777&r2=2.2326.2.778 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.272.2.12&r2=1.272.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.346&r2=1.3389.2.347 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050113-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050113-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17297
[Bug middle-end/19164] [3.3/3.4/4.0 Regression] ICE in digest_init or build_vector
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 09:45 --- Subject: Bug 19164 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-19 09:44:49 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050113-1.c gcc/testsuite/gcc.dg: 20050113-1.c Log message: PR c/17297 * c-typeck.c (digest_init): Only call build_vector if all constructor elements are *_CST nodes. * gcc.c-torture/compile/20050113-1.c: New testcase. PR middle-end/19164 * c-typeck.c (digest_init): Only call build_vector if inside_init is a CONSTRUCTOR. * gcc.dg/20050113-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.777&r2=2.2326.2.778 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.272.2.12&r2=1.272.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.346&r2=1.3389.2.347 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050113-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050113-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19164
[Bug c/17297] [3.4/4.0 Regression] ICE with FP vector constructor containing qnan calculation
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-19 09:49 --- Fixed in CVS. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17297
[Bug libgcj/19527] New: libgij fails to install in a temporary directory
installing with DESTDIR set to a temporary installation directory, the installation fails when relinking libgij. The failure is hidden, if libgcj can be found elsewhere on the system. Matthias libtool: install: warning: relinking `libgij.la' (cd /home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/i486-linux/libjava; /bin/sh ./li btool --mode=relink /home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/gcc/xgcc -shared -libgcc -B/home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/gcc/ -nostdinc++ -L/home/p ackages/gcc/4.0/gcc-4.0-4.0ds4/build/i486-linux/libstdc++-v3/src -L/home/package s/gcc/4.0/gcc-4.0-4.0ds4/build/i486-linux/libstdc++-v3/src/.libs -B/usr/i486-lin ux/bin/ -B/usr/i486-linux/lib/ -isystem /usr/i486-linux/include -isystem /usr/i4 86-linux/sys-include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -W switch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fno-omit-frame-pointer -I/usr/ X11R6/include -Wextra -Wall -D_GNU_SOURCE -DPREFIX="/usr" -DLIBDIR="/usr/lib" -D BOOT_CLASS_PATH="/usr/share/java/libgcj-4.0.0.jar" -DJAVA_EXT_DIRS="/usr/share/j ava/ext" -g -O2 -D_GNU_SOURCE -o libgij.la -rpath /usr/lib/../lib gij.lo libgcj. la) /home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/gcc/xgcc -shared-libgcc -B/home/pack ages/gcc/4.0/gcc-4.0-4.0ds4/build/gcc/ -nostdinc++ -L/home/packages/gcc/4.0/gcc- 4.0-4.0ds4/build/i486-linux/libstdc++-v3/src -L/home/packages/gcc/4.0/gcc-4.0-4. 0ds4/build/i486-linux/libstdc++-v3/src/.libs -B/usr/i486-linux/bin/ -B/usr/i486- linux/lib/ -isystem /usr/i486-linux/include -isystem /usr/i486-linux/sys-include -shared -nostdlib /usr/lib/gcc/i486-linux/../../../lib/crti.o /home/packages/gc c/4.0/gcc-4.0-4.0ds4/build/gcc/crtbeginS.o .libs/gij.o -Wl,--rpath -Wl,/usr/li b/../lib -L/home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/i486-linux/libstdc++-v3/ src -L/home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/i486-linux/libstdc++-v3/src/.l ibs -L/usr/lib/../lib -lgcj -L/home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/i486-l inux/libjava -L/home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/gcc -L/usr/lib/gcc/i4 86-linux/../../../lib -L/usr/lib/gcc/i486-linux/../.. -L/lib/../lib -lgcc_s -lc -lgcc_s /home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/gcc/crtendS.o /usr/lib/gcc/ i486-linux/../../../lib/crtn.o -Wl,-soname -Wl,libgij.so.0 -o .libs/libgij.so.0 .0.0 /usr/bin/ld: cannot find -lgcj collect2: ld returned 1 exit status libtool: install: error: relink `libgij.la' with the above command before instal ling it -- Summary: libgij fails to install in a temporary directory Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19527
[Bug target/19528] New: [4.0 regression] missing ra.h
Today's (2005-01-19) gcc trunk does not build for sh-rtems*: ... make[1]: Entering directory `/users/rtems/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc' gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/. -I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include \ ../../gcc-4.0.0/gcc/config/sh/sh.c -o sh.o ../../gcc-4.0.0/gcc/config/sh/sh.c:50:16: ra.h: No such file or directory ../../gcc-4.0.0/gcc/config/sh/sh.c: In function `push_regs': ../../gcc-4.0.0/gcc/config/sh/sh.c:5049: warning: implicit declaration of function `hard_regs_intersect_p' make[1]: *** [sh.o] Error 1 make[1]: Leaving directory `/users/rtems/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc' As it seems to me, this patch might have broken the sh: 2005-01-17 Paolo Bonzini <[EMAIL PROTECTED]> * common.opt (-fnew-ra): Remove. * ra*.*: Remove. * toplev.h (flag_new_regalloc): Remove. * Makefile.in (ra*.*): Don't mention. * passes.c (rest_of_handle_new_regalloc): Remove. (rest_of_handle_combine, rest_of_compilation): Always consider flag_new_regalloc as false. * doc/invoke.texi: Don't document -fnew-ra. -- Summary: [4.0 regression] missing ra.h Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com GCC target triplet: sh-rtems, sh-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug middle-end/19164] [3.3 Regression] ICE in digest_init or build_vector
-- What|Removed |Added Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19164
[Bug other/19525] [4.0 Regression] In-build-tree multilib testing broken
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-19 09:55 --- At the risk of stating the obvious, I think this is wider than just Solaris and IRIX. Build-directory testing is broken for similarly- organised *-linux-gnu configurations too. I think it's less likely to be noticed there because gcc is the system compiler, and so it's highly likely that the standard library directories will contain a version of libgcc.so.1. In those circumstances, executables that use the non-default multilibs will usually load OK, but they'll be using the system libgcc.so.1, not the newly-built libgcc. This kind-of invalidates the results. I see this on mips64-linux-gnu, for example. Test results for the non-default multilibs are great, but they're using the system DSO (which is from gcc 3.4, as it happens), not the newly-built one. -- What|Removed |Added GCC host triplet|*-*-irix* *-*-solaris* |*-*-irix* *-*-solaris* ||mips64*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
[Bug bootstrap/19529] New: [4.0 regression] sh-rtems multilibs broken
RTEMS is relying on the set of multilibs having been used by default before gcc-4.0.0, i.e. # sh-rtems-gcc --print-multi-lib .; ml;@ml m2;@m2 m3e;@m3e m4-single-only;@m4-single-only m4-single;@m4-single m4;@m4 ml/m2;@[EMAIL PROTECTED] ml/m3e;@[EMAIL PROTECTED] ml/m4-single-only;@[EMAIL PROTECTED] ml/m4-single;@[EMAIL PROTECTED] ml/m4;@[EMAIL PROTECTED] # sh-rtems-gcc --version sh-rtems-gcc (GCC) 3.2.3 Some time between 3.2.3 and gcc-4.0 the default set of multilibs has changed into ml/mb. These are do not meet RTEMS requirements and are unsuiteable for RTEMS. I plan to submit/commit suiteable patches to config.gcc and config/sh/t-rtems to provide custom multilibs which match the old default. -- Summary: [4.0 regression] sh-rtems multilibs broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com GCC target triplet: sh-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19529
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pcarlini at suse dot de 2005-01-19 10:05 --- Well, I can see that basic_string default allocator, std::allocator according to the standard shall return memory only aligned as CharT requests, not more; whereas our implementation of std::allocator provides stronger alignment guarantees. But I can also see that the general requirements in the standard for allocators do *not* talk about alignment at all... Therefore, probably, it would be nice if basic_string could make use of memory only aligned as CharT wants, not more, but, AFAICS, this principle is not present in the original design. I don't think we can implement it now, for 4.0, without changing the ABI. I think we should just document that for our current basic_string memory rerurned by the allocator should be maximally aligned (in some cases less aligned is ok, but details become tricky to spell out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug other/19525] [4.0 Regression] In-build-tree multilib testing broken
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-19 10:13 --- Confirmed by Richard. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 10:13:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
[Bug rtl-optimization/15139] [3.4 Regression] cc1 uses excessive amounts of memory compiling small routine
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 11:18 --- Subject: Bug 15139 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-19 11:18:20 Modified files: gcc: ChangeLog params.def combine.c Makefile.in params.h gcc/testsuite : ChangeLog gcc/doc: invoke.texi Added files: gcc/testsuite/gcc.dg: 20050111-2.c Log message: PR rtl-optimization/15139 * combine.c: Include params.h. (count_rtxs): New function. (record_value_for_reg): If replace_rtx would replace at least 2 occurrences of REG in VALUE and TEM is really large, replace REG with (clobber (const_int 0)) instead of TEM. * params.def (PARAM_MAX_LAST_VALUE_RTL): New. * params.h (MAX_LAST_VALUE_RTL): New. * Makefile.in (combine.o): Depend on $(PARAMS_H). * doc/invoke.texi (--param max-last-value-rtl=N): Document. * gcc.dg/20050111-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.778&r2=2.2326.2.779 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.33.4.2&r2=1.33.4.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.400.4.12&r2=1.400.4.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1223.2.21&r2=1.1223.2.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.16&r2=1.16.16.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.347&r2=1.3389.2.348 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.390.2.34&r2=1.390.2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050111-2.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15139
[Bug rtl-optimization/15139] [3.4 Regression] cc1 uses excessive amounts of memory compiling small routine
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-19 11:21 --- Fixed in CVS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15139
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pcarlini at suse dot de 2005-01-19 11:51 --- For 4.0, besides the documentation issue, I think we should change ext/array_allocator to use tr1::type_traits::aligned_storage, finally available. I will post a patch ASAP... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug java/19505] Java bytecode ICE in except.c remove_unreachable_regions
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 12:11:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
12:21 ---
I am not even going to try and look surprised, the SH port is a major
abuser of the middle-end. But of course, hard_regs_intersect_p should
have been in hard-reg-set.h from the start, *sigh*, mess-meets-mess.
Try this:
Index: hard-reg-set.h
===
RCS file: /cvs/gcc/gcc/gcc/hard-reg-set.h,v
retrieving revision 1.25
diff -u -3 -p -r1.25 hard-reg-set.h
--- hard-reg-set.h 15 Jan 2005 16:06:14 - 1.25
+++ hard-reg-set.h 19 Jan 2005 12:21:01 -
@@ -499,4 +499,19 @@ extern const char * reg_class_names[];
#define REG_CANNOT_CHANGE_MODE_P(REGN, FROM, TO) \
CANNOT_CHANGE_MODE_CLASS (FROM, TO, REGNO_REG_CLASS (REGN))
+/* Determine if two hard register sets intersect.
+ Return 1 if they do. */
+
+static inline bool
+hard_regs_intersect_p (HARD_REG_SET *a, HARD_REG_SET *b)
+{
+ HARD_REG_SET c;
+ COPY_HARD_REG_SET (c, *a);
+ AND_HARD_REG_SET (c, *b);
+ GO_IF_HARD_REG_SUBSET (c, reg_class_contents[(int) NO_REGS], lose);
+ return 1;
+lose:
+ return 0;
+}
+
#endif /* ! GCC_HARD_REG_SET_H */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19 12:26 --- ...and remove the #include "ra.h" of course. Paolo, you should also update doc/passes.texi, which also still has references to new-ra. -- What|Removed |Added CC||bonzini at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 12:26:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug fortran/19362] ICE in fold_convert, at fold-const.c:1998
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-19 12:37 --- As this bug is blocking some of my code, I did some testing of the patch provided in comment #2. Bootstrapped and no additional regression on sparc-sun-solaris2.9. It fixes the testcase all right. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19362
[Bug fortran/19294] intrinsic_transpose.f90 runtime crash
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-19 12:38 --- I tested the patch from comment #8. Bootstrapped and regtested on sparc-sun-solaris2.9. This fixes the intrinsic_transpose.f90 failure all right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19294
[Bug ada/19519] GNAT Bug Box when reading a program with UTF-8 encoded enumeration literals
--- Additional Comments From bauhaus at futureapps dot de 2005-01-19 12:40 --- Created an attachment (id=7990) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7990&action=view) test case as a file attachment, as requested also triggered by this compiler: +===GNAT BUG DETECTED==+ | 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) (i486-pc-linux-gnu) | | Constraint_Error s-wchcnv.adb:150 explicit raise | | Error detected at oeaeue.adb:13:4| -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19519
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-01-19 12:55 --- Subject: Re: [4.0 regression] missing ra.h steven at gcc dot gnu dot org wrote: > --- Additional Comments From steven at gcc dot gnu dot org 2005-01-19 > 12:26 --- > ...and remove the #include "ra.h" of course. Doh. I'm sorry for the breakage, but why the heck does the SH back-end have to include it? Why does the SH back-end have to behave different from every other one?^A^K Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
--- Additional Comments From ch at csh-consult dot dk 2005-01-19 13:06 --- Does this mean that there is a limit to how many files you can compile at a time (due to limited memory)? Can't the garbage collector run between each compilation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-19 13:27 --- I've fixed the doc/passes.texi (commit in progress). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug other/19525] [4.0 Regression] In-build-directory multilib testing broken
-- What|Removed |Added Keywords||build Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-19 13:47 --- Steven, building cc1 to sh-unknown-elf with your patch succeeded. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug target/19528] [4.0 regression] missing ra.h
-- What|Removed |Added Keywords||build Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 13:57 --- (In reply to comment #5) > Does this mean that there is a limit to how many files you can compile at a > time (due to limited memory)? Can't the garbage collector run between each > compilation? Yes for limited by memory but GCC should not be as a hug of memory usage as shown by me looking into how to solve memory usage. Yes the garbage collector runs but the problem is we keep around too much still after the compiler like FUNCTION_TYPEs which seems like most of those should be able to be shared. I will attach later today the a tar ball with one of the files since that is really all that is needed to reproduce this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
[Bug libgcj/19527] libgij fails to install in a temporary directory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 14:01 --- To me it looks like a libtool bug but I could be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19527
[Bug target/19529] [4.0 regression] sh-rtems multilibs broken
-- What|Removed |Added Component|bootstrap |target Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19529
[Bug target/19529] [4.0 regression] sh-rtems multilibs broken
-- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19529
[Bug target/19528] [4.0 regression] missing ra.h
-- What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug c++/19375] [3.4/4.0 Regression] Access violation diagnostic given twice
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 14:30 --- Subject: Bug 19375 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-19 14:30:24 Modified files: gcc/cp : ChangeLog semantics.c Log message: PR c++/19375 * semantics.c (finish_id_expression): Disable access checking for already lookuped FIELD_DECL. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4585&r2=1.4586 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.456&r2=1.457 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19375
[Bug c++/19258] [3.4 Regression] Incorrect access check for default argument
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 14:46 --- Subject: Bug 19258 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-19 14:46:35 Modified files: gcc/cp : ChangeLog parser.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: friend6.C Log message: PR c++/19258 * parser.c (cp_parser_late_parsing_default_args): Handle friend defined in class. * pt.c (push_access_scope, pop_access_scope): Likewise. * g++.dg/lookup/friend6.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.190&r2=1.3892.2.191 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.48&r2=1.157.2.49 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.48&r2=1.816.2.49 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.348&r2=1.3389.2.349 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/friend6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19258
[Bug c++/19258] [3.4 Regression] Incorrect access check for default argument
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-19 14:47 --- Fixed in 3.4 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19258
[Bug c++/19375] [3.4/4.0 Regression] Access violation diagnostic given twice
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 14:50 --- Subject: Bug 19375 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-19 14:50:27 Modified files: gcc/cp : ChangeLog semantics.c Log message: PR c++/19375 * semantics.c (finish_id_expression): Disable access checking for already lookuped FIELD_DECL. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.191&r2=1.3892.2.192 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.381.4.16&r2=1.381.4.17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19375
[Bug c++/19375] [3.4/4.0 Regression] Access violation diagnostic given twice
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-19 14:51 --- Fixed in 3.4 branch and mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19375
[Bug regression/19530] New: MMX load intrinsic produces SSE superflus instructions (movlps)
When I compile this code :
#include
__m64 moo(int i) {
__m64 tmp = _mm_cvtsi32_si64(i);
return tmp;
}
With (GCC) 4.0.0 20050116 like so:
gcc -O3 -S -mmmx moo.c
I get this (without the function pop/push etc)
movd12(%ebp), %mm0
movq%mm0, (%eax)
However, if I use the -msse flag instead of -mmmx, I get this:
movd12(%ebp), %mm0
movq%mm0, -8(%ebp)
movlps -8(%ebp), %xmm1
movlps %xmm1, (%eax)
gcc 3.4.2 does not display this behavior. I didn't get the chance to test it on
my Linux installation yet, but I'm pretty sure it's going to give the same
results.. I didn't use any special flags configuring or building gcc (just
../gcc-4.0-20050116/configure --enable-languages=c,c++ , and make bootstrap)
With -O0 flag instead of -O3, we see that it seems that gcc replaced some movq's
by movlps's (why??) and they do not get cancelled out during optimization..
I will attach the .i file generated by "gcc -O3 -S -msse moo.c".
I also tried a "direct conversion":
__m64 tmp = (__m64) (long long) i;
But I get a compiler error:
internal compiler error: in convert_move, at expr.c:367
--
Summary: MMX load intrinsic produces SSE superflus instructions
(movlps)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guardia at sympatico dot ca
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug regression/19530] MMX load intrinsic produces SSE superflus instructions (movlps)
--- Additional Comments From guardia at sympatico dot ca 2005-01-19 14:59 --- Created an attachment (id=7991) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7991&action=view) gcc -O3 -S -msse moo.c --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug regression/19530] MMX load intrinsic produces SSE superflus instructions (movlps)
-- What|Removed |Added CC||rth at gcc dot gnu dot org Keywords||missed-optimization, ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superflus instructions (movlps)
-- What|Removed |Added Component|regression |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superflus instructions (movlps)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 15:07 --- Hmm, looking at the rtl dumps this looks like the register allocator sucks as the sse register is picked in the -msse but in the -mmmx, only the mmx register is picked. Someone needs to take an axe to the register allocator :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug tree-optimization/19484] [4.0 Regression] function pointer propagation fails for noreturn functions
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-19 15:17 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-17 16:16:47 |2005-01-19 15:17:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19484
[Bug c++/19531] New: RVO is performed on volatile temporary
RVO is performed on a temporary object that is declared volatile.
That seems contradictory with the ISO standards 12.8 15 (object and copy must
have the same cv-unqualified type).
With the following piece of code, I was excepting the copy constructor and
destructor to be called.
struct String
{
int field;
String();
String(int);
~String();
String (const String &);
String (volatile const String &);
};
String name()
{
volatile String t(777);
return t;
}
checking !TREE_VOLATILE (r) in finish_function where the named return value
optimization is set up fixes the problem.
--
Summary: RVO is performed on volatile temporary
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot bruel at st dot com
CC: gcc-bugs at gcc dot gnu dot org
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=19531
[Bug c++/19532] New: cp/pt.c mentions a function that has been removed.
Note that do_pending_inlines has been removed with http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01574.html However, cp/pt.c still mentions do_pending_inlines like so /* Returns 1 if processing DECL as part of do_pending_inlines needs us to push template parms. */ static int inline_needs_template_parms (tree decl) -- Summary: cp/pt.c mentions a function that has been removed. Product: gcc Version: unknown Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19532
[Bug c++/19531] NRV is performed on volatile temporary
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 15:38 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Known to fail||4.0.0 3.1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 15:38:39 date|| Summary|RVO is performed on volatile|NRV is performed on volatile |temporary |temporary http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19531
[Bug c++/19532] cp/pt.c mentions a function that has been removed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 15:39 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 15:39:33 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19532
[Bug tree-optimization/13000] [3.4/4.0 Regression] [unit-at-a-time] Using -O2 cannot detect missing return statement in a function
--- Additional Comments From ian at airs dot com 2005-01-19 15:51 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01223.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13000
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-19 15:57 --- Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | > Does this behaviour seem a little bit unusual to you? You said: "You | > cannot create a basic_string object in memory aligned one". | > That is rather counter-intuitive to a user of libstdc++ who has no | > understanding of the implementation details of basic_string. | | I don't think so. Memory provided by new, f.i., is never returned aligned | one. Quite to the contrary, *missing* a knowledge of the internal impl | details, you are supposed to pass to the string object an allocator | returning memory maximally aligned (like the default one does!) I don't understand the reasoning here. The allocator is that for char, which is required to provide storagte aligned only for char, i.e. in this particular case. Therefore we have real issue with _Rep. This is basically the same issue as the one filled by James Kanze. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-19 16:02 --- Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Well, I can see that basic_string default allocator, std::allocator | according to the standard shall return memory only aligned as CharT requests, | not more; whereas our implementation of std::allocator provides stronger | alignment guarantees. But I can also see that the general requirements in | the standard for allocators do *not* talk about alignment at all... well, I don't think we can go very far with that stretch :-) | Therefore, probably, it would be nice if basic_string could make use of | memory only aligned as CharT wants, not more, but, AFAICS, this principle Yes. Basically, we need to have tha aligned attribute work correctly. | is not present in the original design. I don't think we can implement it | now, for 4.0, without changing the ABI. I think we should just document | that for our current basic_string memory rerurned by the allocator should | be maximally aligned (in some cases less aligned is ok, but details become | tricky to spell out). I rather we fix it. Remember, this is more an optimization issue than a semantics issue. An optimization issue that had causes us more trouble than benefits I believe. I don't believe it is wise for us to go that path down putting more an more restrictions. With people playing with fancy allocator around, it is likely that we're going to have more and more of this issue popping up. In some sense, I'm happy that C++ finally gives progremmers ways to crontrol storage allocation. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From law at redhat dot com 2005-01-19 16:22 --- Subject: Re: DSE is not doing its job for global variables On Wed, 2005-01-19 at 09:12 +, stevenb at novell dot com wrote: > --- Additional Comments From stevenb at novell dot com 2005-01-19 09:12 > --- > Subject: Re: DSE is not doing its job for global variables > > > Do you happen to have numbers on how many dead stores the RTL dead > store elimination (in flow.c, right) catches? Unfortunately, no. I doubt I've run those numbers since the original RTL DSE code was installed several years ago. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-19 16:35 --- (In reply to comment #5) > Steven, building cc1 to sh-unknown-elf with your patch succeeded. Building sh-rtems4.7 with Steven's patch also succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug rtl-optimization/19462] generating return insns while current_function_epilogue_delay_list nonempty
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 16:41 --- Subject: Bug 19462 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-19 16:39:27 Modified files: gcc: ChangeLog reorg.c Log message: PR rtl-optimization/19462 * reorg.c (find_end_label): Create return insn only if current_function_epilogue_delay_list is empty. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7186&r2=2.7187 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reorg.c.diff?cvsroot=gcc&r1=1.102&r2=1.103 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19462
[Bug c/19533] New: Win32 API START_PAGE_GENERAL constant not exists
In the headers from gcc for Windows, the file commdlg.h doesn't contain START_PAGE_GENERAL's constant. (use with the structure PRINTDLGEX - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/commondialogboxlibrary/commondialogboxreference/commondialogboxstructures/printdlgex.asp) To fix it: #define START_PAGE_GENERAL 0x -- Summary: Win32 API START_PAGE_GENERAL constant not exists Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fossar at free dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19533
[Bug c/19533] START_PAGE_GENERAL
-- What|Removed |Added Summary|Win32 API START_PAGE_GENERAL|START_PAGE_GENERAL |constant not exists | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19533
[Bug tree-optimization/19534] New: ICE in create_tmp_var, at gimplify.c:368 (boost_1_32_0 python/bienstman1)
I build gcc from the actual snapshot gcc-4.0-20050116. When I compile boost_1_32_0 I get an ICE when I execute the self tests: Michael Cieslinski g++ -c -o bienstman1.o bienstman1.ii /home/cie019/boost/boost_1_32_0/boost/python/detail/destroy.hpp: In static member function 'static void boost::python::detail::value_destroyer::execute(const volatile T*) [with T = V]': /home/cie019/boost/boost_1_32_0/boost/python/detail/destroy.hpp:90: instantiated from 'void boost::python::detail::destroy_referent_impl(void*, T& (*)()) [with T = const V]' /home/cie019/boost/boost_1_32_0/boost/python/detail/destroy.hpp:101: instantiated from 'void boost::python::detail::destroy_referent(void*, T (*)()) [with T = const V&]' /home/cie019/boost/boost_1_32_0/boost/python/converter/rvalue_from_python_data.h pp:135: instantiated from 'boost::python::converter::rvalue_from_python_data::~rvalue_from_python_ data() [with T = const V&]' /home/cie019/boost/boost_1_32_0/boost/preprocessor/iteration/detail/local.hpp:34 : instantiated from 'PyObject* boost::python::detail::caller_arity<1u>::impl::operator() (PyObject*, PyObject*) [with F = const A* (*)(const V&), Policies = boost::python::return_value_policy, Sig = boost::mpl::vector2]' /home/cie019/boost/boost_1_32_0/boost/python/object/py_function.hpp:38: instantiated from 'PyObject* boost::python::objects::caller_py_function_impl::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller, boost::mpl::vector2 >]' ../../../libs/python/test/bienstman1.cpp:38: instantiated from here /home/cie019/boost/boost_1_32_0/boost/python/detail/destroy.hpp:33: internal compiler error: in create_tmp_var, at gimplify.c:368 Please submit a full bug report, with preprocessed source if appropriate. gcc -v Using built-in specs. Configured with: ../gcc40/configure --with-arch=opteron --enable- languages=c,c++ --enable-checking Thread model: posix gcc version 4.0.0 20050116 (experimental) -- Summary: ICE in create_tmp_var, at gimplify.c:368 (boost_1_32_0 python/bienstman1) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19534
[Bug tree-optimization/19534] ICE in create_tmp_var, at gimplify.c:368 (boost_1_32_0 python/bienstman1)
--- Additional Comments From micis at gmx dot de 2005-01-19 16:48 --- Created an attachment (id=7992) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7992&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19534
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19
17:04 ---
Mark, your response addresses the original message but not the later ones, and
not either of the attached test cases. In those the class is:
class bc {
public:
char m1 :17;
};
m1 is assigned a value of 1, which certainly fits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug libstdc++/19535] New: Wrong return types for __pair_get<1>
In tr1/utility:
template<>
struct __pair_get<1>
{
template
static _Tp1& __get(std::pair<_Tp1, _Tp2>& __pair)
{ return __pair.second; }
template
static const _Tp1& __const_get(const std::pair<_Tp1, _Tp2>& __pair)
{ return __pair.second; }
};
These functions should return (const) _Tp2&, since the type of __pair.second
is _Tp2.
--
Summary: Wrong return types for __pair_get<1>
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peturr02 at ru dot is
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19535
[Bug rtl-optimization/19462] generating return insns while current_function_epilogue_delay_list nonempty
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19 17:04 --- Subject: Bug 19462 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-19 17:04:25 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/torture: pr19462-1.c Log message: PR rtl-optimization/19462 * gcc.dg/torture/pr19462-1.c: Remove token xfail marker. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4910&r2=1.4911 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/pr19462-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19462
[Bug libstdc++/19535] Wrong return types for __pair_get<1>
--- Additional Comments From peturr02 at ru dot is 2005-01-19 17:06 --- Created an attachment (id=7993) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7993&action=view) Test case Compiling this fails with: g++0116 -Wall -static 1.cc -o 1 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In function typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2> >::type& std::tr1::get(std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = A, _Tp2 = B]: 1.cc:9: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:80: error: invalid initialization of reference of type B& from expression of type A /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In function const typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2> >::type& std::tr1::get(const std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = B, _Tp2 = A]: 1.cc:12: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:85: error: invalid initialization of reference of type const A& from expression of type const B /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In static member function static _Tp1& std::tr1::__pair_get<1>::__get(std::pair<_T1, _T2>&) [with _Tp1 = A, _Tp2 = B]: /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:80: instantiated from typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2> >::type& std::tr1::get(std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = A, _Tp2 = B] 1.cc:9: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:70: error: invalid initialization of reference of type A& from expression of type B /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility: In static member function static const _Tp1& std::tr1::__pair_get<1>::__const_get(const std::pair<_T1, _T2>&) [with _Tp1 = B, _Tp2 = A]: /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:85: instantiated from const typename std::tr1::tuple_element<_Int, std::pair<_Tp1, _Tp2> >::type& std::tr1::get(const std::pair<_Tp1, _Tp2>&) [with int _Int = 1, _Tp1 = B, _Tp2 = A] 1.cc:12: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include/c++/tr1/utility:74: error: invalid initialization of reference of type const B& from expression of type const A make: *** [1] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19535
[Bug debug/19521] [4.0 Regression] omitted stab for gcov initialization function
--- Additional Comments From stuart at apple dot com 2005-01-19 17:08 --- > So the bug is the end stab without the start stab? Yes. > Or do you think that this > bit of code that corresponds not at all to any user code should have full > stabs? My personal preference is a mild "yes." But I can forsee that others will disagree, and I recognize the validity of that position. > If the later, why? When I'm grubbing through a broken binary, it's helpful when the debugger tells me that this function body didn't come from the user's sourcecode. In general, "more information is better." I suppose the counterargument would be that most users don't look at the assembly code, don't want to know about these functions, and would prefer smaller debug information for faster linking and development. I assume that most GCC users are unlike me, this I infer their argument wins. I can live with that; this is not a big deal either way. If the debugger already knows the name of this function, and the stabs are not adding any useful information, then I agree they're a waste and should be omitted. The big deal is that the begin/end stabs should match, both emitted or both omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug tree-optimization/19536] New: ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test)
I build gcc from the actual snapshot gcc-4.0-20050116. When I compile boost_1_32_0 I get an ICE when I execute the self tests. This ICE only occurs if I use the "-g" option. Michael Cieslinski g++ -g -c -o current_function_test.o current_function_test.ii ../libs/utility/test/../current_function_test.cpp: In function 'void message (const char*, long int, const char*, const char*)': ../libs/utility/test/../current_function_test.cpp:27: internal compiler error: tree check: expected class 'declaration', have 'exceptional' (@@dummy) in lookup_decl_die, at dwarf2out.c:5415 Please submit a full bug report, with preprocessed source if appropriate. gcc -v Using built-in specs. Configured with: ../gcc40/configure --with-arch=opteron --enable- languages=c,c++ --enable-checking Thread model: posix gcc version 4.0.0 20050116 (experimental) -- Summary: ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19536
[Bug tree-optimization/19536] ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test)
--- Additional Comments From micis at gmx dot de 2005-01-19 17:11 --- Created an attachment (id=7994) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7994&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19536
[Bug rtl-optimization/19462] generating return insns while current_function_epilogue_delay_list nonempty
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-19 17:18 --- All committed to main trunk. (May reopen for branches.) -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19462
[Bug target/19537] New: tic4x does not build -- ICE in libgcc
This does not appear to be the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436. binutils 2.15, gcc from CVS as or 2005-01-19. This should be reproducible in any other tic4x target. ./gcc/configure --target=tic4x-rtems4.7 --enable-threads=rtems --prefix=/opt/rtems-test --with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --enable-version-specific-runtime-libs --enable-languages=c /usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/gcc/xgcc -B/usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/gcc/ -nostdinc -B/usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/tic4x-rtems4.7/newlib/ -isystem /usr3/ftp_archive/gnu/gcc/ss/b-head/b-tic4x-rtems4.7/tic4x-rtems4.7/newlib/targ-include -isystem /usr3/ftp_archive/gnu/gcc/ss/b-head/gcc/newlib/libc/include -B/opt/rtems-test/tic4x-rtems4.7/bin/ -B/opt/rtems-test/tic4x-rtems4.7/lib/ -isystem /opt/rtems-test/tic4x-rtems4.7/include -isystem /opt/rtems-test/tic4x-rtems4.7/sys-include -O2 -I../../gcc/gcc/../newlib/libc/sys/rtems/include -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dexit=unused_exit -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../gcc/gcc -I../../gcc/gcc/ -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -DL_subvsi3 -c ../../gcc/gcc/libgcc2.c -o libgcc/./_subvsi3.o ../../gcc/gcc/libgcc2.c: In function '__do_global_ctors': ../../gcc/gcc/libgcc2.c:1674: internal compiler error: in integer_all_onesp, at tree.c:995 Please submit a full bug report, -- Summary: tic4x does not build -- ICE in libgcc Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: tic4x-rtems, tic4x-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19537
[Bug target/18434] [4.0 Regression] Cannot build gnattools on Tru64 UNIX V5.1B
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:24 --- Tru64 is not a primary or secondary platform; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug target/19392] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/931004-11.c execution, -O0
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:32 --- MMIX is not a primary or secondary target; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19392
[Bug c/19533] START_PAGE_GENERAL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 18:38 --- Not a gcc bug, report this either to cygwin or mygwin as they provide the headers. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19533
[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 18:39 --- *** Bug 19534 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19299
[Bug tree-optimization/19534] ICE in create_tmp_var, at gimplify.c:368 (boost_1_32_0 python/bienstman1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 18:38 --- I already reduced this, this is a dup of bug 19299. *** This bug has been marked as a duplicate of 19299 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19534
[Bug tree-optimization/19536] ICE: tree check: lookup_decl_die, at dwarf2out.c:5415 (boost_1_32_0 utility/current_function_test)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 18:41 --- This is a dup of bug 19367 which is already reduced. *** This bug has been marked as a duplicate of 19367 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19536
[Bug c++/19367] [4.0 Regression] ICE: tree_check in lookup_local_die with local `using'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 18:41 --- *** Bug 19536 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19367
[Bug target/14798] [3.4/4.0 Regression] In case of SH target with -O2 option #pragma interrupt doesn't get resetted.
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:43 --- SH is not a primary or secondary target; removing target milestone. -- What|Removed |Added Target Milestone|3.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14798
[Bug c++/18279] [4.0 regression] missing function bodies from -fdump-translation-unit
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:45 --- This option is only designed for use in debugging the compiler. As it's not designed for use by end-users, I've removed the target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18279
[Bug target/18346] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/trampoline-1.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:47 --- MMIX is not a primary or secondary platform; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18346
[Bug target/18335] [3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/debug/debug-1.c and debug-2 xyzzy
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:47 --- MMIX is not a primary or secondary platform; removing target milestone. -- What|Removed |Added Target Milestone|3.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18335
[Bug rtl-optimization/18485] [4.0 regression] mmix-knuth-mmixware testsuite failure: g++.dg/lookup/forscope1.C g++.old-deja/g++.niklas/t132.C g++.old-deja/g++.other/singleton.C
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:47 --- MMIX is not a primary or secondary platform; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18485
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:52 --- Ada and Java bugs are not release-critical; therefore, I've removed the target milsetone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug ada/19456] [4.0 regression] ada bootstrap failure on alpha-linux
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:51 --- Ada and Java bugs are not release-critical; therefore, I've removed the target milsetone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19456
[Bug java/18399] [4.0 Regression] Class initialization optimization does not work with the inliner
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:52 --- Ada and Java bugs are not release-critical; therefore, I've removed the target milsetone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/16885] [4.0 Regression] java/awt/Container.java build failure with parallel make
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:52 --- Ada and Java bugs are not release-critical; therefore, I've removed the target milsetone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16885
[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:52 --- Ada and Java bugs are not release-critical; therefore, I've removed the target milsetone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19295
[Bug java/18190] [4.0 regression] primitive array optimization is gone
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19 18:52 --- Ada and Java bugs are not release-critical; therefore, I've removed the target milsetone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18190
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19 18:59 --- Good. Ralf, can you post it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19 19:24 --- Mark, can we keep known wrong-code bugs targeted for 4.0 please? Java/Ada or other languages shouldn't make a difference for wrong code bugs. They are the most serious kind we have. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19295
[Bug tree-optimization/18441] Vectorizer: add a command line for simple vectorizer report
--- Additional Comments From leehod at il dot ibm dot com 2005-01-19 19:28 --- There is now a patch addressing these issues. See: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01247.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441
[Bug java/16885] [4.0 Regression] java/awt/Container.java build failure with parallel make
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 19:32 --- I just to be able to reproduce this all the time too but lately (in the last two months) I have not been able to so closing as fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16885
[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)
--- Additional Comments From andreev at comm dot mot dot com 2005-01-19 19:33 --- There is no config.log file in libstdc++ directory. And I have target's /usr/lib and /usr/include directories in location specified by --with- sysroot -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19 19:36 --- This config.log: ./i686-pc-solaris2.8/libstdc++-v3/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)
--- Additional Comments From andreev at comm dot mot dot com 2005-01-19 19:38 --- (In reply to comment #5) > This config.log: > ./i686-pc-solaris2.8/libstdc++-v3/config.log Andrew, there is no such file, look at comment #2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
