[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-27 13:25 --- Actually this looks like it is picking up a different libiconv rather than anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug c++/19614] Excessive memory consumption with a class with large (200) virtual (pure?) function and derived classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-27 13:24 --- (In reply to comment #6) > I checked out CVS head on 1/27/2005. The memory consumption on this file on > x86_64 was "only" 750M. I don't know if this qualifies as excessive or not so > I'll let someone else close it. 750M for me is still excessive. I and other people will look into this soon (again). -- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-01-25 00:07:34 |2005-01-27 13:24:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
[Bug target/19655] bug when make all
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-27 13:21 --- This cross build works for me and many other people. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19655
[Bug tree-optimization/18595] [4.0 Regression] IV-OPTS is O(N^3)
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-01-27 13:18 ---
Subject: Re: [4.0 Regression] IV-OPTS is O(N^3)
With the following patch I got some speedup for depth 100.
from:
tree iv optimization : 2.62 (62%) usr 0.27 (82%) sys 2.92 (62%) wall
tree iv optimization : 2.33 (59%) usr 0.25 (83%) sys 2.63 (54%) wall
to:
tree iv optimization : 1.19 (46%) usr 0.04 (40%) sys 1.26 (45%) wall
tree iv optimization : 1.21 (47%) usr 0.05 (45%) sys 1.30 (46%) wall
Basically we're reseting too much information each time scev_reset is
called. It would even be possible to reset only the part of the scev
database that contains symbols instead of erasing everything.
Do somebody know how to iterate over all the elements of the hash
setting to NULL_TREE the elements that answer true to
chrec_contains_symbols?
Index: tree-scalar-evolution.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-scalar-evolution.c,v
retrieving revision 2.16
diff -d -u -p -r2.16 tree-scalar-evolution.c
--- tree-scalar-evolution.c 18 Jan 2005 11:36:26 - 2.16
+++ tree-scalar-evolution.c 27 Jan 2005 13:12:36 -
@@ -2490,7 +2490,7 @@ scev_reset (void)
for (i = 1; i < current_loops->num; i++)
{
loop = current_loops->parray[i];
- if (loop)
+ if (loop && chrec_contains_symbols (loop->nb_iterations))
loop->nb_iterations = NULL_TREE;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-27 13:06 --- Example failure log: Executing on host: /usr/home/wanderer/pkg/build/gcc/obj/gcc/g++ -shared- libgcc -B/usr/home/wanderer/pkg/build/gcc/obj/gcc/ -nostdinc++ - L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++- v3/src -L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/src/.libs -B/home/wanderer/pkg/gcc/i386-unknown- freebsd5.3/bin/ -B/home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/lib/ - isystem /home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/include - isystem /home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/sys-include -g -O2 - D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 - DLOCALEDIR="/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/po/share/locale" -nostdinc++ - I/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++- v3/include/i386-unknown-freebsd5.3 -I/usr/home/wanderer/pkg/build/gcc/obj/i386- unknown-freebsd5.3/libstdc++-v3/include - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++-v3/libsupc++ - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++-v3/include/backward - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite /home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite/22_locale/collate/compare/wchar_t/2.cc -finput-charset=ISO8859- 1 -L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/./libstdc++- v3/testsuite -lv3test -lm -o ./2.exe(timeout = 300) spawn /usr/home/wanderer/pkg/build/gcc/obj/gcc/g++ -shared-libgcc - B/usr/home/wanderer/pkg/build/gcc/obj/gcc/ -nostdinc++ - L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++- v3/src -L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/src/.libs -B/home/wanderer/pkg/gcc/i386-unknown- freebsd5.3/bin/ -B/home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/lib/ - isystem /home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/include - isystem /home/wanderer/pkg/gcc/i386-unknown-freebsd5.3/sys-include -g -O2 - D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 - DLOCALEDIR="/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/po/share/locale" -nostdinc++ - I/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++- v3/include/i386-unknown-freebsd5.3 -I/usr/home/wanderer/pkg/build/gcc/obj/i386- unknown-freebsd5.3/libstdc++-v3/include - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++-v3/libsupc++ - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++-v3/include/backward - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite /home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite/22_locale/collate/compare/wchar_t/2.cc -finput-charset=ISO8859-1 - L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/./libstdc++- v3/testsuite -lv3test -lm -o ./2.exe cc1plus: error: no iconv implementation, cannot convert from ISO8859-1 to UTF-8 /home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite/22_locale/collate/compare/wchar_t/2.cc:27:18: error: no iconv implementation, cannot convert from ISO8859-1 to UTF-8 In file included from /home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite/22_locale/collate/compare/wchar_t/2.cc:27: /usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++- v3/include/locale:43:28: error: no iconv implementation, cannot convert from ISO8859-1 to UTF-8 In file included from /usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/include/locale:43, from /home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite/22_locale/collate/compare/wchar_t/2.cc:27: /usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++- v3/include/bits/localefwd.h:45:28: error: no iconv implementation, cannot convert from ISO8859-1 to UTF-8 In file included from /usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/include/bits/localefwd.h:45, from /usr/home/wanderer/pkg/build/gcc/obj/i386-unknown- freebsd5.3/libstdc++-v3/include/locale:43, from /home/wanderer/pkg/build/gcc/src/gcc/gcc/libstdc++- v3/testsuite/22_locale/collate/compare/wchar_t/2.cc:27: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug c++/19614] Excessive memory consumption with a class with large (200) virtual (pure?) function and derived classes
--- Additional Comments From dmartin at cliftonlabs dot com 2005-01-27 13:04 --- I checked out CVS head on 1/27/2005. The memory consumption on this file on x86_64 was "only" 750M. I don't know if this qualifies as excessive or not so I'll let someone else close it. -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
--- Additional Comments From wanderer at rsu dot ru 2005-01-27 13:02 --- Can be related to PR18360 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug bootstrap/18360] Can't bootastrap gcc 3.4.3 at FreeBSD using gcc mainline
--- Additional Comments From wanderer at rsu dot ru 2005-01-27 13:01 --- Sorry, can be related PR19656 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18360
[Bug bootstrap/18360] Can't bootastrap gcc 3.4.3 at FreeBSD using gcc mainline
--- Additional Comments From wanderer at rsu dot ru 2005-01-27 12:59 --- Can be related to PR18360 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18360
[Bug libstdc++/19656] New: libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD
If i bootstrap using installed some old or same CVS mainline gcc (a.k.a. gcc 4.0.0) i have in testsuit results: === libstdc++ Summary === # of expected passes3472 # of unexpected failures1 # of unexpected successes 1 # of expected failures 5 If i bootstrap using gcc 3.4.3 version i have in testsuit results: === libstdc++ Summary === # of expected passes3454 # of unexpected failures10 # of unexpected successes 1 # of expected failures 5 contrib/compare_tests output: Tests that now fail, but worked before: 22_locale/collate/compare/wchar_t/2.cc (test for excess errors) 22_locale/collate/compare/wchar_t/wrapped_env.cc (test for excess errors) 22_locale/collate/compare/wchar_t/wrapped_locale.cc (test for excess errors) 22_locale/collate/hash/wchar_t/2.cc (test for excess errors) 22_locale/collate/hash/wchar_t/wrapped_env.cc (test for excess errors) 22_locale/collate/hash/wchar_t/wrapped_locale.cc (test for excess errors) 22_locale/collate/transform/wchar_t/2.cc (test for excess errors) 22_locale/collate/transform/wchar_t/wrapped_env.cc (test for excess errors) 22_locale/collate/transform/wchar_t/wrapped_locale.cc (test for excess errors) Old tests that passed, that have disappeared: (Eeek!) 22_locale/collate/compare/wchar_t/2.cc execution test 22_locale/collate/compare/wchar_t/wrapped_env.cc execution test 22_locale/collate/compare/wchar_t/wrapped_locale.cc execution test 22_locale/collate/hash/wchar_t/2.cc execution test 22_locale/collate/hash/wchar_t/wrapped_env.cc execution test 22_locale/collate/hash/wchar_t/wrapped_locale.cc execution test 22_locale/collate/transform/wchar_t/2.cc execution test 22_locale/collate/transform/wchar_t/wrapped_env.cc execution test 22_locale/collate/transform/wchar_t/wrapped_locale.cc execution test I have all *.sum and *.log files from both tastsuite runs and can post its if requared -- Summary: libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wanderer at rsu dot ru CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-unknown-freebsd5.3 GCC host triplet: i386-unknown-freebsd5.3 GCC target triplet: i386-unknown-freebsd5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
[Bug c++/18370] [3.4 Regression] cp_parser_initializer_list uninit variable problems
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-27 12:57 --- Subject: Bug 18370 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-27 12:57:43 Modified files: gcc: ChangeLog real.c Log message: gcc: * real.c (do_add): Initialize signalling and canonical members. * real.c (real_from_integer): Zero out destination. gcc/cp: PR c++/18370 * parser.c (cp_parser_initializer_clause): Initialize *non_constant_p. 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.784&r2=2.2326.2.785 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/real.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.135.4.6&r2=1.135.4.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18370
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-27 12:57 --- Eh! The runtimes are indeed **very** interesting, thanks! And, also, it looks like I was wrong in the last comment: in case LC_ALL is set, this is automatically seen in setlocale(LC_NUMERIC, 0), therefore your suggestion of changing my patch to just use LC_NUMERIC should work well! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c++/18370] [3.4 Regression] cp_parser_initializer_list uninit variable problems
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-27 12:55 --- Subject: Bug 18370 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-27 12:54:40 Modified files: gcc/cp : ChangeLog parser.c Log message: gcc: * real.c (do_add): Initialize signalling and canonical members. * real.c (real_from_integer): Zero out destination. gcc/cp: PR c++/18370 * parser.c (cp_parser_initializer_clause): Initialize *non_constant_p. 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.192&r2=1.3892.2.193 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.49&r2=1.157.2.50 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18370
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 12:54 --- I think this runtimes of the different setlocale() calls might be interesting: (This is for 100 calls) category locale time LC_ALL00.70s LC_NUMERIC00.29s LC_ALL "C" 1.63s LC_NUMERIC "C" 8.98s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug java/19586] gij exits with SIGABR
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-27 12:48 --- > > Now it sounds like your machine has bad memory. Can you check your memory? > > I don't think so it probebly some bad updated env-vars that were back to > correct > values after a re-login or something like that. > > But if it is my memory how do I test it? Is it a program I can use? Try either Memtest86 (http://www.memtest86.com/) or Memtest86+ (http://www.memtest.org/). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19586
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-27 12:46 --- Thanks! For the correctness issue, notice that LC_ALL overrides any LC_*, therefore checking only LC_NUMERIC seems weaker, still, probably effective in most circumstances... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 12:39 --- A quick test shows, that std::setlocale(LC_ALL, NULL) returns "C C C C C C". But std::setlocale(LC_NUMERIC, NULL) returns "C" I think it is enough to test LC_NUMERIC. I'll try to test a modified patch. But this may take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c/18946] [4.0 regression] ICE in pushdecl
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-27 12:39 --- Fixed in CVS. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18946
[Bug c/18946] [4.0 regression] ICE in pushdecl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-27 12:38 --- Subject: Bug 18946 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-27 12:38:38 Modified files: gcc: ChangeLog c-decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/noncompile: 20050120-1.c Log message: PR c/18946 * c-decl.c (warn_if_shadowing): Handle old_decl error_mark_node. (pushdecl): Only use DECL_FILE_SCOPE_P if DECL_P. (implicitly_declare): Handle error_mark_node. * gcc.dg/noncompile/20050120-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7303&r2=2.7304 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.626&r2=1.627 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4941&r2=1.4942 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/noncompile/20050120-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18946
[Bug target/19655] New: bug when make all
hello all, i am trying to build a tool chain with binutils-2.14, and gcc-3.3.2. i faced an error when make all is given at gcc-3.3.2. the error is as follows: In file included from tconfig.h:22, from libgcc2.c:36: config/rs6000/linux.h:89:20: signal.h: No such file or directory In file included from tconfig.h:22, from libgcc2.c:36: config/rs6000/linux.h:98: error: parse error before "stack_t" config/rs6000/linux.h:98: warning: no semicolon at end of struct or union config/rs6000/linux.h:100: error: parse error before "uc_sigmask" config/rs6000/linux.h:100: warning: type defaults to `int' in declaration of `uc _sigmask' config/rs6000/linux.h:100: warning: data definition has no type or storage class config/rs6000/linux.h:99: error: storage size of `uc_mcontext' isn't known make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/home/sudheer/ToolChain/Test_Ftpgnu/gcc-3.3.2/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/sudheer/ToolChain/Test_Ftpgnu/gcc-3.3.2/gcc' make: *** [all-gcc] Error 2 You have new mail in /var/spool/mail/root ** i have copied the signal.h from gcc-3.3.2/gcc/fixinc/tests/base/sys/signal.h to an /opt/usr/local/powerpc-linux/include/ and tried but i still face the syntax errors that appear earlier, but now no signl.h error. i request you to kindly respond as soon as possible. thanks & regards sudheer -- Summary: bug when make all Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s_anumolu at rediffmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: gcc 3.3.2 GCC host triplet: i686 linux gnu GCC target triplet: mpc 8540 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19655
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-27 12:31 --- Notice, however, that as-is, the patch is not perfect from the correctness point of view: we should also check LC_NUMERIC... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-27 12:25 --- Can you test the attached? Should help, and we can apply it in 3_4-branch, maybe in mainline too depending on the res of 17140. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug fortran/19654] New: compilation crashes when variable is too large instead of showing error
GNU Fortran 95 (GCC 4.0.0 20050127 (experimental))
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED] guillem $ gfc kk.f90 -lfftw3f
kk.f90: In function 'MAIN__':
kk.f90:14: internal compiler error: in tree_low_cst, at tree.c:3816
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
ifort{
[EMAIL PROTECTED] guillem $ ifort -v
Version 8.1
} gives
[EMAIL PROTECTED] guillem $ ifort kk.f90 -lfftw3f
fortcom: Error: kk.f90, line 10: A common block or variable may not exceed
2147483647 bytes
real, dimension(N,N):: output
-^
fortcom: Error: kk.f90, line 9: A common block or variable may not exceed
2147483647 bytes
real, dimension(N,N):: input
-^
compilation aborted for kk.f90 (code 1)
program kk
implicit none
include "/usr/include/fftw3.f"
integer, parameter :: N=32768, M=N/2-1
real, dimension(N,N):: input
real, dimension(N,N):: output
integer(8):: plan
call random_number(input)
open(12,file='fisico')
open(13,file='fourier')
call sfftw_plan_dft_r2c_2d(plan,N,N,input,output,FFTW_ESTIMATE)
call sfftw_execute(plan)
call sfftw_destroy_plan(plan)
end program kk
Linked with fftw3, but not relevant (I presume)
--
Summary: compilation crashes when variable is too large instead
of showing error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillemborrell at yahoo dot es
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=19654
[Bug ada/19488] RTEMS Ada RTS doesn't compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-27 11:53 --- Subject: Bug 19488 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-27 11:52:50 Modified files: gcc/ada: ChangeLog 5rosinte.ads 5rtpopsp.adb gsocket.h Log message: 2005-01-27 Joel Sherrill <[EMAIL PROTECTED]> Laurent GUERBY <[EMAIL PROTECTED]> PR ada/19488 * 5rosinte.ads: Add No_Key constant. * 5rtpopsp.adb: Initialize ATCB_Key with No_Key and fix style. * gsocket.h: Do not include with RTEMS either. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.629&r2=1.630 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/5rosinte.ads.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/5rtpopsp.adb.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/gsocket.h.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19488
[Bug other/13573] Manual changes from GCC book need to be merged
--- Additional Comments From joseph at codesourcery dot com 2005-01-27 11:34 --- Subject: Re: Manual changes from GCC book need to be merged On Thu, 27 Jan 2005, pinskia at gcc dot gnu dot org wrote: > Any more news on this one (or the patch has to be reduced further?). The last attached diffs represents the current set of diffs which need individual logical changes extracting, converting to equivalent logical mainline changes and reviewing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13573
[Bug libstdc++/19648] stl_alloc.h - increases required alignment of target type
--- Additional Comments From pcarlini at suse dot de 2005-01-27 11:16 --- No this is an old issue, fixed by Gerald Pfeifer on May, 20, 2003 (cannot find the PR #, sorry). No recent release is affected. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19648
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-27 11:11 --- Hi everyone. No, switching by hand to "C" locale cannot help, because, given the current generic locale model, the setlocale calls are issued *anyway*. Indeed, we could envisage improving on this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27 10:24 --- /me should read up on the amd64 instruction set first :-( -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27 10:23 --- moron alert -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27 10:13 --- More knowledgable sources than me say: "[mov %eax, %eax ] is not nop. 32bit operations implicitly zero extend, so this is zero extension. There is no movqzx." -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug c++/14329] [tree-ssa] badly formatted warnings for SRA replacements
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 09:33 --- C++ front end left to update. See http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01988.html for an example of something that almost but does not quite work. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Component|tree-optimization |c++ Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug tree-optimization/14329] [tree-ssa] badly formatted warnings for SRA replacements
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-27 09:29 --- Subject: Bug 14329 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-27 09:28:46 Modified files: gcc: ChangeLog c-objc-common.c dwarf2out.c toplev.c tree-outof-ssa.c tree-sra.c tree.h var-tracking.c Added files: gcc/testsuite/gcc.dg: uninit-I.c Log message: PR tree-opt/14329 * tree.h (struct tree_decl): Add debug_expr_is_from. (DECL_DEBUG_EXPR_IS_FROM): New. (DECL_DEBUG_EXPR): Rename from DECL_DEBUG_ALIAS_OF. * dwarf2out.c (dwarf2out_var_location): Update to match. * tree-outof-ssa.c (create_temp): Likewise. * var-tracking.c (track_expr_p): Likewise. * tree-sra.c (instantiate_element): Set DECL_DEBUG_EXPR. * c-objc-common.c (c_tree_printer) <'D'>: Handle DECL_DEBUG_EXPR. * toplev.c (default_tree_printer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7302&r2=2.7303 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-objc-common.c.diff?cvsroot=gcc&r1=1.60&r2=1.61 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.568&r2=1.569 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.940&r2=1.941 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcc&r1=2.42&r2=2.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-sra.c.diff?cvsroot=gcc&r1=2.50&r2=2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.682&r2=1.683 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/var-tracking.c.diff?cvsroot=gcc&r1=2.25&r2=2.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/uninit-I.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From uros at kss-loka dot si 2005-01-27 09:14 --- A patch (RFC actually) that was used to teach allocator which register set to use: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01783.html [This patch probably doesn't work well with xmmintrin.h stuff as pointed by rth in follow-up comment.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug rtl-optimization/8126] [3.3/3.4/4.0 regression] Floating point computation far slower in 3.2 than in 2.95
--- Additional Comments From uros at kss-loka dot si 2005-01-27 09:07 --- I don't think that this has anything to do with regstack and sched2. The fact is, that for fp-intensive applications, 8 FP regs (either stacked x87 or non-stack SSE type) is not enough. When there is a shorthage of registers, gcc starts to swap registers to and from memory. Please note that reg/reg and reg/mem fops have the same latency/throuhput on P4, but moving FP registers to and from memory introduces a big performance penalty and these moves should be minimised as much as possible. There are some measurements to prove this (-O2 only to avoid fast-math intrinsic shortcuts, P4-3.2 timings): a) -march=pentium -mfpmath=387: scheduling and reg-stack interactions: real0m34.073s user0m33.756s sys 0m0.018s b) -march=pentium -msse2 -mfpmath=sse: scheduling and no reg-stack: real0m35.063s user0m34.674s sys 0m0.076s c) -march=pentium4 -mfpmath=387: no scheduling with reg-stack: real0m33.720s user0m33.348s sys 0m0.037s d) -march=pentium4 -mfpmath=sse: no scheduling and no reg-stack: real0m35.399s user0m35.016s sys 0m0.035s The question I would like to ask: is there a functionality in gcc to optimise register moving, considering the cost of reg/reg vs. reg/mem FP operators and the cost of register<->mem move? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8126
[Bug middle-end/19652] should always optimize constant second argument to strspn & Co. at compile time
--- Additional Comments From falk at debian dot org 2005-01-27 09:02 --- (In reply to comment #0) > strspn, strcspn, strpbrk functions make a bitmap out of their second argument > and then process their first argument using that bitmap. > If the second argument is a constant string, that bitmap should be built at > the > compile time, and strspn call be replaced with some intrinsic function that > can > use that bitmap. Well, with that we'd be wandering off far into libc land. While this kind of optimization is nice, I wouldn't really want to have strspn code for 40 platforms in gcc to maintain (and if you're that desperate for speed, you want platform-specific code). Alternatively, you could try to convince your libc providers to include such functions in their libc, and then we might implement calling them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19652
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From uros at kss-loka dot si 2005-01-27 08:35 --- Created an attachment (id=8080) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8080&action=view) Self-contained example Self-contained example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug target/19653] New: x87 reg allocated for constants for -mfpmath=sse
A self-contained testcase is attached to this bugreport. Please compile it with
-O2 -march=pentium4 -mfpmath=sse -ffast-math.
This part of the testcase:
...
if ( fabs(fabs(NewRay->Direction[Z])- 1.) < .1 ) {
/* too close to vertical for comfort, so use cross product with horizon */
up[X] = 0.; up[Y] = 1.; up[Z] = 0.;
}
else
{
up[X] = 0.; up[Y] = 0.; up[Z] = 1.;
}
VCross(n2, NewRay->Direction, up); VNormalizeEq(n2);
VCross(n3, NewRay->Direction, n2); VNormalizeEq(n3);
...
will generate:
jae .L2
fldz
fstl-112(%ebp)
movsd -112(%ebp), %xmm2
fld1
fstpl -112(%ebp)
movsd -112(%ebp), %xmm1
.L5:
fldl32(%ebx)
fstpl -96(%ebp)
movsd -96(%ebp), %xmm3
mulsd %xmm2, %xmm3
movapd %xmm5, %xmm0
mulsd %xmm1, %xmm0
subsd %xmm0, %xmm3
fldl24(%ebx)
fstpl -88(%ebp)
mulsd -88(%ebp), %xmm2
xorpd .LC5, %xmm2
movsd -88(%ebp), %xmm4
...
.L2:
fld1
fstpl -112(%ebp)
movsd -112(%ebp), %xmm2
fldz
fstl-112(%ebp)
movsd -112(%ebp), %xmm1
jmp .L5
Uros.
--
Summary: x87 reg allocated for constants for -mfpmath=sse
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
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=19653
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-27 08:08 --- std::cout.imbue( std::locale( "C" ) ); nor std::cout.imbue( std::locale::classic() ); nor export LANG=C does change anything Joerg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
