[Bug libfortran/19216] list directed read with leading slash (NIST FM923)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18 07:05 --- Subject: Bug 19216 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-18 07:05:28 Modified files: gcc/testsuite : ChangeLog Log message: PR libfortran/19216 * gfortran.dg/pr19216.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5362&r2=1.5363 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
[Bug libfortran/19216] [4.0 only] list directed read with leading slash (NIST FM923)
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:18 --- This is fixed by Paul T. Richard's namelist patch, but there still is a testcase (gfortran.dg/pr19216.f) to commit on 4.0 branch. -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-04-07 07:19:43 |2005-04-18 07:18:07 date|| Summary|list directed read with |[4.0 only] list directed |leading slash (NIST FM923) |read with leading slash ||(NIST FM923) Version|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
[Bug libfortran/20950] segfault in INQUIRE asking for SEQUENTIAL status
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18 07:34 --- Subject: Bug 20950 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-18 07:34:33 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : inquire.c Added files: gcc/testsuite/gfortran.dg: pr20950.f Log message: PR libfortran/20950 * io/inquire.c (inquire_via_unit): Check for the gfc_unit being NULL when setting ioparm.sequential. * gfortran.dg/pr20950.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5363&r2=1.5364 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20950.f.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.196&r2=1.197 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/inquire.c.diff?cvsroot=gcc&r1=1.10&r2=1.11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20950
[Bug libfortran/18392] [4.0 only] segfault on derived type namelist input
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:39 --- This is indeed legal, and fixed by Thomas's recent namelist patch. Will have to be committed on 4.0 once it's open again. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-18 07:39:46 date|| Summary|segfault on derived type|[4.0 only] segfault on |namelist input |derived type namelist input Version|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18392
[Bug libfortran/20950] [4.0 only] segfault in INQUIRE asking for SEQUENTIAL status
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:40 --- Patch commited to mainline. Waiting for 4.0 to reopen. -- What|Removed |Added Keywords||patch Last reconfirmed|2005-04-11 15:41:15 |2005-04-18 07:40:41 date|| Summary|segfault in INQUIRE asking |[4.0 only] segfault in |for SEQUENTIAL status |INQUIRE asking for ||SEQUENTIAL status Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20950
[Bug libfortran/12884] [4.0] error in reading a namelist when it is predeced by a line with a SLASH
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:44 --- This is fixed by Paul's recent namelist patch, applied on mainline. Will be fixed on 4.0 once it's reopened. -- What|Removed |Added Keywords||patch Last reconfirmed|2004-09-09 18:34:41 |2005-04-18 07:44:28 date|| Summary|[Regression w.r.t. g77] |[4.0] error in reading a |error in reading a namelist |namelist when it is predeced |when it is predeced by a|by a line with a SLASH |line with a SLASH | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12884
gcc-bugs@gcc.gnu.org
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:46 --- This one is fixed by the recent namelist patch, will be fixed on 4.0 when it's reopened. -- What|Removed |Added Keywords||patch Last reconfirmed|2005-03-29 01:52:23 |2005-04-18 07:46:32 date|| Summary|namelist write does not |[4.0 only] namelist write |terminate with &end |does not terminate with &end Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17285
[Bug libfortran/18122] [4.0 only] gfortran internal error in namelist read
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:50 --- Fixed by the recent namelist patch. Will be fixed on 4.0 once it's reopened. -- What|Removed |Added Keywords||patch Summary|gfortran internal error in |[4.0 only] gfortran internal |namelist read |error in namelist read Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18122
[Bug libfortran/18210] namelist output format problems
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:52 --- The uppercase problem is fixed by Paul's recent patch on mainline (will be fixed on 4.0 once it's reopened). Leave this bug open until someone can confirm if leading space is required for namelist output (all compilers I could test seems to put a leading space, but that's no proof). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18210
[Bug libfortran/18879] [4.0 only] ? not supported in namelist input
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:54 --- This is an extension indeed, and is incorporated in mainline by Paul's recent namelist patch. Will be included in 4.0 when it reopens. -- What|Removed |Added Keywords||patch Summary|? not supported in namelist |[4.0 only] ? not supported |input |in namelist input http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18879
[Bug libf2c/19657] Namelist reading may be skipped if end with a logical variable
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 07:59 --- Confirm this bug. This is g77-only. Changed component to libf2c. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libf2c Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-18 07:59:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19657
[Bug fortran/17472] [4.0 only] namelist does not handle arrays
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 08:02 --- Fixed by Paul's recent namelist patch. Will be fixed on 4.0 when it's reopened. -- What|Removed |Added Keywords||patch Summary|namelist does not handle|[4.0 only] namelist does not |arrays |handle arrays Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17472
[Bug libfortran/18591] gfortran: internal error with namelist
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 08:05 --- This is a duplicate of 18122 (which has just been fixed). *** This bug has been marked as a duplicate of 18122 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18591
[Bug libfortran/18122] [4.0 only] gfortran internal error in namelist read
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 08:05 --- *** Bug 18591 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18122
[Bug fortran/19467] [4.0 only] ICE caused by CHARACTER array in NAMELIST read or write
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 08:06 --- Fixed by Paul's recent namelist patch. Will be fixed on 4.0 when it's reopened. -- What|Removed |Added Keywords||patch Summary|ICE caused by CHARACTER |[4.0 only] ICE caused by |array in NAMELIST read or |CHARACTER array in NAMELIST |write |read or write http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19467
[Bug libstdc++/16611] Terrible code generated for vector
--- Additional Comments From falk at debian dot org 2005-04-18 08:10 --- (In reply to comment #6) > Hi. It can well be a libstdc++ problem, and indeed I can imagine ways to avoid > signed integers in the code. However, I'm not sure that someone will actually > do the work, given the soon-to-be-deprecated status of vector... This is news to me. Does this mean that vector is not going to be special- cased any more? That seems like a very bad idea to me, since programs will suddenly take 8 times as much memory (or even more). What's the rationale? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From adah at netstd dot com 2005-04-18 09:06 --- Function calls, memory barriers, (and "lock" operations?) are all overheads. I would like that * GCC provide extensions so that GCC users can use memory barriers and threading calls in a platform-independent way, and * - Revert the patch, or at least - Provide a command-line option (or pragma/attribute?) to disable/enable static initialization protection. With the former, users can implement the protection as efficiently as the compiler can (correct me if I am wrong). With the latter, the new GCC is still usable in some applications that require performance no less than C. I am really worried that with the improvements introduced to GCC beginning with GCC 3, some of my applications are running slower and slower, though some problems only show up on Windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug c++/17445] too few template-parameter-lists
--- Additional Comments From giovannibajo at libero dot it 2005-04-18 09:08 --- A segfault in GCC is always a bug, even if the code is wrong. Would you please open a new bugreport about it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
[Bug target/20633] libgcc2.c:1623: error: size of array 'compile_type_assert' is negative
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-18 09:23 --- I messed up the quotation too. :-( It should read: #undef CPP_SPEC #define CPP_SPEC" \ %(cpp_cpu) \ %(cpp_arch) \ %{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic_} \ %{posix:-D_POSIX_SOURCE} \ " -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20633
[Bug tree-optimization/18316] Missed IV optimization
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-04-18 09:33 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01959.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
[Bug target/21007] [4.1 Regression] gcc.c-torture/execute/931004-2.c execution fails on hppa64-hpux and cris-elf
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-18 11:16 --- Appeared on hppa64-hpux between 2005-04-09 01:34 UTC and 2005-04-09 01:38 UTC. I.e., caused by tree-cleanup-branch merge. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21007
[Bug c++/21084] New: parse error on valid dependent default argument
template< typename _Key,typename _Val,typename _KeyOfValue,typename _Compare,typename _Alloc> class _Rb_tree; template< typename _Key,typename _Compare,typename _Alloc >class multiset{ multiset(_Compare const& __comp, typename _Rb_tree<_Key,_Key,_Key ,_Compare,_Alloc > ::allocator_type const& __a=_Rb_tree<_Key,_Key,_Key ,_Compare,_Alloc > ::allocator_type()); }; accepted if the allocator_type is typedef'ed and the default argument is constructed through the typedef name. gcc version 4.0.0 20050415 (prerelease) gcc-Version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) -- Summary: parse error on valid dependent default argument Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21084
[Bug middle-end/21006] [4.1 Regression] g++.dg/other/static11.C fails
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-18 11:20 --- Appeared on x86_64-linux between 2005-04-12 21:33 UTC and 2005-04-12 21:37 UTC. I.e., caused by 2005-04-12 Steven Bosscher <[EMAIL PROTECTED]> Stuart Hastings <[EMAIL PROTECTED]> Jan Hubicka <[EMAIL PROTECTED]> * Makefile.in: Add function.h to BASIC_BLOCK_H. Remove all references to gt-tree-cfg.h. * basic-block.h (struct basic_block_def): Don't skip rbi for garbage collection. (struct reorder_block_def): Make GTY-able. (struct control_flow_graph): New structure. (n_edges, n_basic_blocks, last_basic_block, basic_block_info, BASIC_BLOCK, EXIT_BLOCK_PTR, ENTRY_BLOCK_PTR): No longer vars, but instead defines to the control_flow_graph for cfun. (label_to_block_map): New define, points to the label map of the control_flow_graph for cfun. (n_edges_for_function, n_basic_blocks_for_function, last_basic_block_for_function, basic_block_info_for_function, EXIT_BLOCK_PTR_FOR_FUNCTION, ENTRY_BLOCK_PTR_FOR_FUNCTION, basic_block_info_for_function, label_to_block_map_for_function): Counterparts for the above, taking a struct function as an extra argument. (alloc_rbi_pool, free_rbi_pool): Remove prototypes. * cfg.c: (n_edges, n_basic_blocks, last_basic_block, basic_block_info, ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR): Remove. (alloc_rbi_pool, free_rbi_pool): Remove. (initialize_bb_rbi): Use ggc_alloc_cleared instead of pool_alloc. * cfglayout.c: (cfg_layout_initialize): Don't allocate the rbi pool here... (cfg_layout_finalize) ... and don't free it here. * cfgrtl.c (cfg_layout_delete_block): Zero out rbi so it gets garbage collected. * flow.c (free_basic_block_vars): Set label_to_block_map and n_edges to zero too. * function.h (struct function): Add cfg field. * function.c (allocate_struct_function): Allocate the cfg. * tree-cfg.c (label_to_block_map): Remove. (build_tree_cfg): Don't allocate the rbi pool here... (delete_tree_cfg_annotations): ...and don't free it here. Also don't nullify label_to_block_map for cfun. -- What|Removed |Added CC||steven at gcc dot gnu dot ||org, stuart at apple dot ||com, hubicka at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21006
[Bug fortran/15335] runtime error "Attempt to allocate a negative amount of memory"
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 12:03 --- Using the testcase from comment #4, it seems clear that there is no check on whether the slice selected has negative width... atmp.2.dim[0].stride = 1; atmp.2.dim[0].lbound = 0; atmp.2.dim[0].ubound = i - 3; D.489 = i - 2; atmp.2.data = (real4[0:] *) _gfortran_internal_malloc (D.489 * 4); -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-02-17 05:04:45 |2005-04-18 12:03:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15335
[Bug c++/21084] parse error on valid dependent default argument
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-18 12:04 --- here's another, simpler, testcase: template< typename T1,typename T2> class A; //it works with only 1 parameter class B{ template void hoh(typename A::depname a=A::depname()); }; I'd appreciate a simple workaround for this one, because you can't typedef the dependent type like in the original testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21084
[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
-- What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug c++/20240] [3.3 Regression] invalid using-redeclaration accepted
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-18 12:08 --- fixed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From matz at suse dot de 2005-04-18 12:49 --- So, any progress on this whole issue? I don't see either the pragmas in the C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS. Just for the record, I see these problems (linkproblem with test from comment #11) also on ppc and ppc64, so it's not just a target dependend problem. On ppc64 it's an unresolvable R_PPC64_REL24 relocation, and on ppc it's simply an undefined reference to the std::string ctor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From matz at suse dot de 2005-04-18 12:50 --- Oh, and just annotating the testcase with the visibility push/pop #pragma is not enough, probably because of the problem in the c++ frontend, HJ noted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 13:12 --- I think I found a patch for this one. See http://gcc.gnu.org/ml/fortran/2005-04/msg00507.html -- What|Removed |Added CC|coudert at clipper dot ens |fxcoudert at gcc dot gnu dot |dot fr |org GCC build triplet|i686-pc-linux | GCC target triplet|i686-pc-linux | Keywords||patch Last reconfirmed|2005-02-26 18:42:24 |2005-04-18 13:12:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug c++/21085] New: Virtual memory exhausted with g++
Hello, there must be a serious problem in GNU C++ version 4.0.0 20050410 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.3.4 (pre 3.3.5 20040809) (SuSE Linux 9.2). The same happens with GNU C++ version 4.0.0 20050410 when built with itself. On a Pentium III 1GHz with enough RAM to avoid swapping, cc1plus will eat memory at about 200MB/sec until the OS kills it, as observable with top at a sub-second interval. The .ii file produced by the issued command has bzipped 131128 bytes. I have not found a sensible way to include that file here, you will find it under http://www-madlener.informatik.uni-kl.de/staff/strieder/triedriver.t.ii.bz2 or I will send it on request. The code used to compile under gcc-2.95, gcc-3.3.x, on i386 ans SPARCs and gcc-3.4.[23] on i386. How the .ii was produced: g++ -v --save-temps -gdwarf-2 -Wall -W -Winline -Woverloaded-virtual -I. -I/home/strieder/xssr/sys -I/home/strieder/xssr/sys/xssr-gui -DINLINE='inline' -DDO_INLINE -c -o triedriver.t.o /home/strieder/xssr/sys/testdrivers/triedriver.t.cc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0-20050410/configure --enable-threads=posix --prefix=/net/opt/gcc-4.0.0-20050410 --enable-languages=c,c++ --with-system-zlib --enable-shared --enable-__cxa_atexit Thread model: posix gcc version 4.0.0 20050410 (prerelease) /net/opt/gcc-4.0.0-20050410/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -E -quiet -v -I. -I/home/strieder/xssr/sys -I/home/strieder/xssr/sys/xssr-gui -D_GNU_SOURCE -DINLINE=inline -DDO_INLINE /home/strieder/xssr/sys/testdrivers/triedriver.t.cc -mtune=pentiumpro -Wall -W -Winline -Woverloaded-virtual -fworking-directory -fpch-preprocess -o triedriver.t.ii ignoring nonexistent directory "/net/opt/gcc-4.0.0-20050410/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: . /home/strieder/xssr/sys /home/strieder/xssr/sys/xssr-gui /net/opt/gcc-4.0.0-20050410/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0 /net/opt/gcc-4.0.0-20050410/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu /net/opt/gcc-4.0.0-20050410/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward /usr/local/include /net/opt/gcc-4.0.0-20050410/include /net/opt/gcc-4.0.0-20050410/lib/gcc/i686-pc-linux-gnu/4.0.0/include /usr/include End of search list. /net/opt/gcc-4.0.0-20050410/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -fpreprocessed triedriver.t.ii -quiet -dumpbase triedriver.t.cc -mtune=pentiumpro -auxbase-strip triedriver.t.o -gdwarf-2 -Wall -W -Winline -Woverloaded-virtual -version -o triedriver.t.s GNU C++ version 4.0.0 20050410 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.3.4 (pre 3.3.5 20040809). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64454 g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. How to reproduce: g++ -Wall -W -Winline -Woverloaded-virtual -I. -I/home/strieder/xssr/sys -I/home/strieder/xssr/sys/xssr-gui -DINLINE='inline' -DDO_INLINE-c -o triedriver.t.o triedriver.t.ii or g++ -c triedriver.t.ii or g++ -O2 -c triedriver.t.ii Regards, Bernd Strieder -- Summary: Virtual memory exhausted with g++ Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: strieder at informatik dot uni-kl dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug c++/17445] too few template-parameter-lists
--- Additional Comments From leslie dot barnes at amd dot com 2005-04-18 13:37 --- (In reply to comment #4) > A segfault in GCC is always a bug, even if the code is wrong. Would you > please > open a new bugreport about it? Sorry, I wasn't clear. The binary seg faults, not the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:14 --- Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end, back-end and library issues. When I'm back from Oxford really want to move the issue forward, somehow, asking all the knowledgeable people (besides doing myself the, rather trivial, it seems, library bits). In the meanwhile, if you are able to see clearly which front-end/back-end patches among all those proposed here and posted on gcc-patches are *definitely* improvements, please patronize and ping on gcc-patches... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug tree-optimization/21086] New: VRP does not extract a value from a comparison expression.
Consider: int foo (int *p) { int a = *p; int b = p != 0; *p = b; if (b) return a; else return 0; } Here is what I get with -O2 -fno-tree-dominator-opts foo (p) { int b; int a; int D.1235; : a_3 = *p_2; p_7 = p_2; b_4 = p_7 != 0B; *p_7 = b_4; p_10 = p_7; if (b_4 != 0) goto ; else goto ; :; a_6 = 0; # a_1 = PHI ; :; return a_1; } Note that the "if" statement is not optimized away. This is because VRP does not extract a value from a comparison expression. -- Summary: VRP does not extract a value from a comparison expression. Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: kazu at cs dot umass dot edu ReportedBy: kazu at cs dot umass dot edu CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21086
[Bug regression/20973] [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From matz at suse dot de 2005-04-18 14:22 --- This patch fixes the regressions in khtml for us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug libstdc++/16611] Terrible code generated for vector
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:23 --- > This is news to me. Does this mean that vector is not going to be > special- > cased any more? That seems like a very bad idea to me, since programs will > suddenly take 8 times as much memory (or even more). What's the rationale? Oh, well, this is a *well* known issue: roughly, the C++ standard committee considers vector a serious mistake, because, in short, doesn't conform to *many* of the standard requirements for containers. The current plan (as of Lillehammer, last week) consists of two parts: 1- Deprecating vector, 2- Adding a new bit_vector container. Of course no one wants to remove the current vector without a replacement. Please Google a bit for further details or ask me privately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
[Bug libfortran/12884] [4.0] error in reading a namelist when it is predeced by a line with a SLASH
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12884
[Bug libfortran/18879] [4.0 only] ? not supported in namelist input
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18879
[Bug fortran/19467] [4.0 only] ICE caused by CHARACTER array in NAMELIST read or write
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19467
[Bug regression/20973] [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-18 14:42 --- Michael, have you run the GCC testsuite with your patch? If not, please run on several platforms and confirm that you get no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug c++/21087] New: ICE in do_nonmember_using_decl
out.cpp:17279: internal compiler error: in do_nonmember_using_decl, at cp/name-lookup.c:2072 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I think the code is valid, though I'm not sure since I don't know what's the cause for this, the line reported, 17279, definitly is valid. attaching source. ICE with: gcc version 4.0.0 20050418 (prerelease) works with: gcc-Version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) -- Summary: ICE in do_nonmember_using_decl Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sstrasser at systemhaus-gruppe dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug regression/20973] [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload
--- Additional Comments From matz at suse dot de 2005-04-18 14:51 --- >From http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01508.html where I submitted the patch: the problem in khtml. I've bootstrapped it with gcc 4.0 on i686,x86_64,ppc,ppc64,ia64,s390 (s390x was breaking for different reasons), all languages (with Ada ;) ). There were no regressions (in fact some fixed Ada testcases, but I'm not sure if they were real). Note the last sentence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
[Bug c++/21087] ICE in do_nonmember_using_decl
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-18 14:51 --- Created an attachment (id=8676) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8676&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug libgcj/10353] [3.3/3.4/4.0/4.1 regression] Java testsuite failures
--- Additional Comments From mckinlay at redhat dot com 2005-04-18 14:55 --- I don't think a gij test failure is expected. Array_3 is known to fail when native compiled, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug tree-optimization/21088] New: VRP passes fold the type of operands of a comparison
Around tree-vrp.c:420, we have t = fold (build2 (LT_EXPR, TREE_TYPE (val1), val1, val2)); if (t == boolean_true_node) return -1; Since VAL1 is known to be of a pointer type, the result of fold will never be equal to boolean_true_node, which is of the boolean type. -- Summary: VRP passes fold the type of operands of a comparison Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: kazu at cs dot umass dot edu ReportedBy: kazu at cs dot umass dot edu CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
[Bug tree-optimization/20922] missed always false conditional
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18 15:18 --- Subject: Bug 20922 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-18 15:18:22 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr20922-1.c pr20922-2.c pr20922-3.c pr20922-4.c pr20922-5.c pr20922-6.c Log message: 2005-04-18 James A. Morrison <[EMAIL PROTECTED]> PR tree-optimization/20922 * fold-const.c (fold_binary): Fold X - c > X and X + c < X to false. Fold X + c >= X and fold X - c <= X to true. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8345&r2=2.8346 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.562&r2=1.563 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5364&r2=1.5365 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20922-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20922-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20922-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20922-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20922-5.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20922-6.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug tree-optimization/20922] missed always false conditional
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-18 15:20 --- Fixed in the last commit. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug middle-end/19986] [meta-bug] fold missing optimizations (compared to RTL)
-- Bug 19986 depends on bug 20922, which changed state. Bug 20922 Summary: missed always false conditional http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19986
[Bug tree-optimization/20922] missed always false conditional
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2
-- What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug middle-end/21049] [4.1 Regression] ICE with -fdump-tree-all and fortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:20 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21049
[Bug middle-end/21049] [4.1 Regression] ICE with -fdump-tree-all and fortran
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18 17:21 --- Subject: Bug 21049 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-18 17:20:57 Modified files: gcc: ChangeLog Log message: Add PR markers to: 2005-04-18 Alexandre Oliva <[EMAIL PROTECTED]> PR middle-end/21049 * tree-cfg.c (dump_function_to_file): Do not crash if cfun or cfun->cfg are NULL. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8352&r2=2.8353 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21049
[Bug tree-optimization/20994] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dpatel at apple dot com 2005-04-18 17:23 --- Subject: Re: [4.1 regression] ICE with -ftree-vectorize This is because invert_truthvalue() does not return valid GIMPLE expr. I've a patch, once it passes usual test cycle, I'll post patch. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20994
[Bug c++/21089] New: c++ accepts invalid static const double members with initializer
See this testcase: - struct Ball { static const double diameter = 20; void setPosition(double ,double ); double vect_Pos; }; void move (double, double); void Ball::setPosition(double xval,double yval) { vect_Pos=xval; move(xval-(diameter/2),yval-(diameter/2)); } - This is from kbilliard, and I only noticed the problem, because a reference to Ball::diameter is left in the generated code, which can't be resolved, as it's defined nowhere. Initially I was tricked by the java like syntax, but then saw PR20098, according to which this is invalid code (for two reasons). So it seems there are two problems: 1) missed optimization, as for instance if I remove the 'vectPos=xval' line I get no linker error, and in fact in the dumps the references to diameter are substituted by the defined value (double)20 2) the invalidness of the code is not diagnosed. It's invalid for two reasons I think, first the missing definition, instead of the declaration. But that can't be diagnosed except by the linker, which indeed it does. But when reading PR20098 I learned that static const members are only allowed to have an initializer when they are of integral type. This is not the case here. If the compiler would have diagnosed it, the root cause of this problem had been more visible. -- Summary: c++ accepts invalid static const double members with initializer Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] c++ accepts invalid static const double members with initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:32 --- Yes this is invalid C++ (and is rejected by -pedantic) but we somehow declared this as an extension see PR 11393 which is still open and other threads within a past year. *** This bug has been marked as a duplicate of 11393 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/11393] Initializer of static const float class member is not legal in c++98
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:32 --- *** Bug 21089 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11393
[Bug c++/11393] Initializer of static const float class member is not legal in c++98
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:38 --- This is a documented deprecated feature: http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html#Deprecated-Features G++ allows static data members of const floating-point type to be declared with an initializer in a class definition. The standard only allows initializers for static members of const integral types and const enumeration types so this extension has been deprecated and will be removed from a future version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11393
[Bug tree-optimization/21090] New: VRP does not notice nonzero-ness from a PHI node
Consider: int g, h; int foo (int a) { int *p; if (a) p = &g; else p = &h; if (p != 0) return 1; else return 0; } With -O2 -fno-dominator-opts, VRP does not optimize away the "if" statement. This is because VRP does not run the propagator when it does not insert any ASSERT_EXPR. Even if I force it to run the propagator by forcing vrp_initialize to return true, the meet function decides that the lattice value of p at the second "if" statement is VARYING. I guess we can teach the meet function to generate ~[0, 0] when we meet &g and &h. -- Summary: VRP does not notice nonzero-ness from a PHI node Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at cs dot umass dot edu CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21090
[Bug c++/21089] c++ accepts invalid static const double members with initializer
--- Additional Comments From matz at suse dot de 2005-04-18 17:40 --- Indeed. Okay, but then this really is an optimization regression compared to gcc 3.3.x which compiled this just fine. As it's only rejected with -pedantic (and I think it's a sensible extension), shouldn't we make sure that we can compile this comparatively simple source, i.e. propagate the constant correctly everywhere? I'm not sure what to do, reopening with a new subject, or creating a new bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] C++ front-end does not "inline" the static const double members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:47 --- (In reply to comment #2) > Indeed. Okay, but then this really is an optimization regression compared > to gcc 3.3.x which compiled this just fine. As it's only rejected with > -pedantic (and I think it's a sensible extension), shouldn't we make sure > that we can compile this comparatively simple source, i.e. propagate > the constant correctly everywhere? I'm not sure what to do, reopening with > a new subject, or creating a new bug? Oh, in that case I will reopen the bug with a different summary. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||missed-optimization Resolution|DUPLICATE | Summary|c++ accepts invalid static |C++ front-end does not |const double members with |"inline" the static const |initializer |double members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:50 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-04-18 17:50:29 date|| Summary|C++ front-end does not |[4.0/4.1 Regression] C++ |"inline" the static const |front-end does not "inline" |double members |the static const double ||members Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:53 --- It has nothing to do with members of classes either, see the following code: static const double a = 1.0; static const double b = a+1.0; double c() { return b; } We now longer inline 2.0 into c. -- What|Removed |Added Summary|[4.0/4.1 Regression] C++|[4.0/4.1 Regression] C++ |front-end does not "inline" |front-end does not "inline" |the static const double |the static const double |members | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 17:56 --- Simple code which shows we now have a missed optimization: static const double a = 1.0; static const double b = a+1.0; double c() { return b; } See PR 21089. -- What|Removed |Added BugsThisDependsOn||21089 Bug 20912 depends on bug 21089, which changed state. Bug 21089 Summary: [4.0/4.1 Regression] C++ front-end does not "inline" the static const double http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Status|UNCONFIRMED |NEWBug 20912 depends on bug 21089, which changed state. Bug 21089 Summary: [4.0/4.1 Regression] C++ front-end does not "inline" the static const double http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Status|UNCONFIRMED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From matz at suse dot de 2005-04-18 17:59 --- With -O0 we also don't inline 'a'. I thought in the past this already was done in the frontend, so the -O option didn't matter? If yes, this has changed (if not, well, I'm wrong ;-) ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-18 17:59 --- The patch in Comment #13 is OK for 4.0.0. It's a pessimization, but it's rather more obviously correct. Please apply forthwith. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:04 --- (In reply to comment #6) > With -O0 we also don't inline 'a'. I thought in the past this already > was done in the frontend, so the -O option didn't matter? If yes, this > has changed (if not, well, I'm wrong ;-) ). The code for 3.4.0 at -O0 for the example in comment #5: .LC0: .long 0 .long 1073741824 .text .align 2 .globl _Z1cv .type _Z1cv, @function _Z1cv: pushl %ebp movl%esp, %ebp fldl.LC0 popl%ebp ret .size _Z1cv, .-_Z1cv .section.rodata .align 8 .type a, @object .size a, 8 a: .long 0 .long 1072693248 .align 8 .type b, @object .size b, 8 b: .long 0 .long 1073741824 so we did inline 2.0 before. The code for 4.0.0 and above is even worse: _Z1cv: pushl %ebp movl%esp, %ebp fldlb popl%ebp ret .size _Z1cv, .-_Z1cv .text .align 2 .type _Z41__static_initialization_and_destruction_0ii, @function _Z41__static_initialization_and_destruction_0ii: pushl %ebp movl%esp, %ebp subl$8, %esp movl%eax, -4(%ebp) movl%edx, -8(%ebp) cmpl$65535, -8(%ebp) jne .L7 cmpl$1, -4(%ebp) jne .L7 fldla fld1 faddp %st, %st(1) fstpl b .L7: leave ret .size _Z41__static_initialization_and_destruction_0ii, .- _Z41__static_initialization_and_destruction_0ii .text .align 2 .type _GLOBAL__I__Z1cv, @function _GLOBAL__I__Z1cv: pushl %ebp movl%esp, %ebp movl$65535, %edx movl$1, %eax call_Z41__static_initialization_and_destruction_0ii popl%ebp ret We dymanically initialize b too which is what partly PR 20912 is about, Diego filed after seeing eon fail because the front-end was still marking b as constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug target/21091] New: -many flag causes problems
When compiling for some specific powerpc targets (405 for instance, but for 403 is also true) the -many flag causes problems. This is added when your compiler command is something like: powerpc-eabi-gcc -c -finline-limit=7000 -msoft-float -mcpu=405 -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -Wp,-MD,... -o ... the real problem is that -many produces assembly codes that must be valid for all ppc targets, so if you have some inline assembly included when as is included it tries to compile the inline assembly (which is specific in my case to 405) and it complains about not being a valid opcode. The solution to this problem is to remove the -many flag. Below is a simple patch against 3.4.3 that fixes this. diff -uNr gcc-3.4.3/gcc/config/rs6000/rs6000.h gcc-3.4.3-patched/gcc/config/rs6000/rs6000.h --- gcc-3.4.3/gcc/config/rs6000/rs6000.h2004-08-23 20:02:58.0 +0200 +++ gcc-3.4.3-patched/gcc/config/rs6000/rs6000.h2005-04-18 19:49:31.0 +0200 @@ -97,8 +97,7 @@ %{mcpu=970: -mpower4 -maltivec} \ %{mcpu=G5: -mpower4 -maltivec} \ %{mcpu=8540: -me500} \ -%{maltivec: -maltivec} \ --many" +%{maltivec: -maltivec}" -- Summary: -many flag causes problems Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlos at mind dot be CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:06 --- Also note this worked with "4.0.0 2004121", so something after that date changed the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug target/21091] -many flag causes problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:10 --- Which binutils are you using because -many changed recently which is why it is done this way in gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug target/21091] -many flag causes problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:11 --- See the thread at http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html to see why -many was added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug target/21091] -many flag causes problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:12 --- And http://sources.redhat.com/bugzilla/show_bug.cgi?id=147 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug target/21091] -many flag causes problems
--- Additional Comments From carlos at mind dot be 2005-04-18 18:13 --- Subject: Re: -many flag causes problems On Monday 18 April 2005 20:10, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 > 18:10 --- Which binutils are you using because -many changed recently > which is why it is done this way in gcc. Hi, currently I'm using binutils-2.14, I tried binutils-2.15 but I get other errors (not sure if they are related to this particular thing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug target/21091] -many flag causes problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:14 --- In my mind MOT messed up by making two different instructions which have the same opcode. Bad MOT (freescale now). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug target/21091] -many flag causes problems
--- Additional Comments From carlos at mind dot be 2005-04-18 18:15 --- Subject: Re: -many flag causes problems On Monday 18 April 2005 20:11, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 > 18:11 --- See the thread at > http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html to see why -many > was added. I read it, but adding -many is not the solution for that. They only need to fix the -mAltivec part, not -many. The worst case scenario is to add -many to all of the targets that require it, but not for targets which are very specific such as some embedded ppc like 403 or 405 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:19 --- (In reply to comment #8) > Also note this worked with "4.0.0 20041211", so something after that date > changed the problem. And it was broken by "4.0.0 20050113". so there is only a month time which it could have changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From jason at redhat dot com 2005-04-18 18:28 --- Subject: Re: local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads On 18 Apr 2005 09:07:00 -, "adah at netstd dot com" <[EMAIL PROTECTED]> wrote: > I would like that > > * GCC provide extensions so that GCC users can use memory barriers and > threading calls in a platform-independent way, and I'd like that too. > - Provide a command-line option (or pragma/attribute?) to disable/enable > static initialization protection. Already there: -fno-threadsafe-statics. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:34 --- Looks like this was caused by: 2004-12-16 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/18905 * cp-tree.h (integral_constant_value): Declare. * call.c (null_ptr_cst_p): Use integral_constant_value, not decl_constant_value. (convert_like_real): Likewise. * class.c (check_bitfield_decl): Likewise. * cvt.c (ocp_convert): Likewise. (convert): Remove unnecessary decl_constant_value call. * decl.c (compute_array_index_type): Use integral_constant_value, not decl_constant_value. (build_enumerator): Likewise. * decl2.c (grokfield): Likewise. * init.c (decl_constant_value): Simplify. (integral_constant_value): New. * pt.c (fold_decl_constant_value): Use integral_constant_value, remove subsequent check. (tsubst): Use integral_constant_value, not decl_constant_value. (tsubst_copy, unify): Likewise. * typeck.c (decay_conversion): Likewise. (build_compound_expr): Remove unnecessary decl_constant_value calls. (build_static_cast_1, build_reinterpret_cast_1): (convert_for_assignment): Remove comment about not calling decl_constant_value. -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug tree-optimization/21081] [4.1 Regression] internal compiler error: verify_stmts failed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:39 --- Can you try this with today's compiler, I cannot reproduce it with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21081
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From sabre at nondot dot org 2005-04-18 18:41 --- Is this optimization valid? Note that it will change the behavior of this c++ program: #include static const double X = 1.0; static struct S { S(); } s; static const double Y = X+2.0; S::S() { printf("%f\n", Y); } int main() {} In particular, I think the C++ standard specifies that memory is zero initialized and then ctors (within a translation unit) are run in order. IANALL though. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21084] parse error on valid dependent default argument
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:42 --- This is a dup of one of the oldest "bug" in the database, PR 57. Basically right now it might be a bug in GCC or GCC is correct in the standard, the work around is the following: template< typename T1,typename T2> class A; //it works with only 1 parameter class B{ template void hoh(typename A::depname a=(A::depname())); }; Note the parenthesizes. *** This bug has been marked as a duplicate of 57 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21084
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 18:42 --- *** Bug 21084 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sstrasser at systemhaus- ||gruppe dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug c++/21087] [4.0/4.1 Regression] ICE in do_nonmember_using_decl
-- What|Removed |Added Summary|ICE in |[4.0/4.1 Regression] ICE in |do_nonmember_using_decl |do_nonmember_using_decl Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug c++/21087] [4.0/4.1 Regression] ICE in do_nonmember_using_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:04 --- Reduced testcase: extern "C" signed int toupper(signed int __c) throw(); namespace std { template< typename a > a toupper(a,int){} using ::toupper; } Note this has to do with builtin functions as if I cange toupper to be named something different I don't get an ICE. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-18 19:04:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
[Bug tree-optimization/21086] VRP does not extract a value from a comparison expression.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:10 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-18 19:10:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21086
[Bug tree-optimization/21088] VRP passes fold the type of operands of a comparison
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:12 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-04-18 19:12:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21088
[Bug tree-optimization/21090] VRP does not notice nonzero-ness from a PHI node
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:13 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-18 19:13:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21090
[Bug middle-end/21085] [4.0/4.1 Regression] Virtual memory exhausted with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:18 --- On the mainline we don't get virtual memory exhausted but that is because there has been a patch or two to fix the memory usage but instead we get stack overflow: #1207 0x002fc6e0 in fold_binary (code=TRUNC_MOD_EXPR, type=0x41d0c780, op0=0x26c9600, op1=0x26b95e0) at /Users/pinskia/src/alias/gcc/gcc/fold-const.c:8509 #1208 0x002fe288 in fold_build2 (code=TRUNC_MOD_EXPR, type=0x26c9600, op0=0x17, op1=0x7) at /Users/pinskia/src/alias/gcc/gcc/fold-const.c:10253 #1209 0x002fc6e0 in fold_binary (code=TRUNC_MOD_EXPR, type=0x41d0c780, op0=0x26c9600, op1=0x26b95c0) at /Users/pinskia/src/alias/gcc/gcc/fold-const.c:8509 #1210 0x002fe288 in fold_build2 (code=TRUNC_MOD_EXPR, type=0x26c9600, op0=0x17, op1=0x7) at /Users/pinskia/src/alias/gcc/gcc/fold-const.c:10253 #1211 0x002fc6e0 in fold_binary (code=TRUNC_MOD_EXPR, type=0x41d0c780, op0=0x26c9600, op1=0x26b95a0) at /Users/pinskia/src/alias/gcc/gcc/fold-const.c:8509 Let me try to get a reduced testcase. -- What|Removed |Added Component|c++ |middle-end Keywords||ice-on-valid-code Summary|Virtual memory exhausted|[4.0/4.1 Regression] Virtual |with g++|memory exhausted with g++ Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug middle-end/21085] [4.0/4.1 Regression] Virtual memory exhausted with g++
-- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug middle-end/21085] [4.0/4.1 Regression] Virtual memory exhausted with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:24 --- Reduced testcase: int main( int argc, char * argv[ ] ) { int maxstringlen = 1; int limit = 0, maxblock = 0, maxblockrem = 0; maxblockrem = (maxstringlen) % (2147483647 + 1); } -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-18 19:24:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug middle-end/21085] [4.0/4.1 Regression] Virtual memory exhausted with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:25 --- (In reply to comment #2) > Reduced testcase: Even though there is an overflow which the C front-end says the code was in an if (0) block so it should not matter about that as it is only undefined then but we still should not be crashing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:29 --- (In reply to comment #3) > Simple code which shows we now have a missed optimization: > static const double a = 1.0; > static const double b = a+1.0; > > double c() > { > return b; > } > > See PR 21089. I believe the optimization necessitates the variable's declaration be changed (either explicitly, or by implication): static const double b = a+1.0; => const double b = a+1.0; If it's static-const value can't be pre-computed at compile time. (as opposed to allowing a non-const-literal value to initialize a global static const object). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:36 --- (In reply to comment #11) I believe the optimization necessitates the variable's declaration be changed (either explicitly, or by implication): static const double b = a+1.0; => const double b = a+1.0; If it's static-const value can't be pre-computed at compile time. (as opposed to allowing a non-const-literal value to initialize a global static const object). (as with: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912 ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21092] New: friend inaccessibility
A recent change on CVS HEAD breaks this: $ cat a.cc class X { friend class Y; friend int foo(const Y&); }; $ g++ -c -W -Wall a.cc a.cc:3: error: expected ',' or '...' before '&' token a.cc:3: error: ISO C++ forbids declaration of 'Y' with no type The original bug report is against CLN with possibly more info of value, and may be read here: http://thep.physik.uni-mainz.de/pipermail/cln-list/2005-April/000119.html AFAIK gcc-4.0.0 is fine. -- Summary: friend inaccessibility Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092
[Bug middle-end/21085] [4.0/4.1 Regression] Virtual memory exhausted with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:38 --- Most likely caused by: 2004-07-05 Roger Sayle <[EMAIL PROTECTED]> * fold-const.c (fold) : Optimize unsigned modulus by a power of two into a bit-wise AND, i.e. "X % C" as "X & (C-1)". Normalize "X % C" as "X % -C" for signed modulus and negative C. Optimize "X % -Y" as "X % Y" for signed modulus. : Recursively call "fold" when transforming "(X % Y) == 0" into "((unsigned) X % Y) == 0". -- What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug c++/21092] friend inaccessibility
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18 19:40 --- No, the code is invalid, as Y has not been interjected yet. This is a progression and not a regression. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092
[Bug tree-optimization/21093] New: missed tail call optimization when local address could escape
Missed tail call optimization when local address could escape but not on the condition: void f(void); void f1(int *); void g(int i, int j) { if (j) return f(); return f1(&i); } This might be a reduced testcase from fold_binary to fold_build2 where we have this issue, but I have not looked through all of the conditionals to see if this is true. -- Summary: missed tail call optimization when local address could escape Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21093
[Bug testsuite/21094] New: libmudflap C++ tests run even when C++ not configured
On 4.0.0 RC1 and RC2, when configuring without C++ some libmudflap tests that look like they're C++ are run and fail. === libmudflap tests === Running target unix FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors) WARNING: libmudflap.c++/fail24-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass27-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass27-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass28-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass28-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass31-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass31-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass41-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass55-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass55-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/fail24-frag.cxx (-static) (test for excess errors) WARNING: libmudflap.c++/fail24-frag.cxx (-static) compilation failed to produce executable FAIL: libmudflap.c++/pass27-frag.cxx (-static) (test for excess errors) WARNING: libmudflap.c++/pass27-frag.cxx (-static) compilation failed to produce executable FAIL: libmudflap.c++/pass28-frag.cxx (-static) (test for excess errors) WARNING: libmudflap.c++/pass28-frag.cxx (-static) compilation failed to produce executable FAIL: libmudflap.c++/pass31-frag.cxx (-static) (test for excess errors) WARNING: libmudflap.c++/pass31-frag.cxx (-static) compilation failed to produce executable FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors) WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed to produce executable FAIL: libmudflap.c++/pass55-frag.cxx (-static) (test for excess errors) WARNING: libmudflap.c++/pass55-frag.cxx (-static) compilation failed to produce executable FAIL: libmudflap.c++/fail24-frag.cxx (-O2) (test for excess errors) WARNING: libmudflap.c++/fail24-frag.cxx (-O2) compilation failed to produce executable FAIL: libmudflap.c++/pass27-frag.cxx (-O2) (test for excess errors) WARNING: libmudflap.c++/pass27-frag.cxx (-O2) compilation failed to produce executable FAIL: libmudflap.c++/pass28-frag.cxx (-O2) (test for excess errors) WARNING: libmudflap.c++/pass28-frag.cxx (-O2) compilation failed to produce executable FAIL: libmudflap.c++/pass31-frag.cxx (-O2) (test for excess errors) WARNING: libmudflap.c++/pass31-frag.cxx (-O2) compilation failed to produce executable FAIL: libmudflap.c++/pass41-frag.cxx (-O2) (test for excess errors) WARNING: libmudflap.c++/pass41-frag.cxx (-O2) compilation failed to produce executable FAIL: libmudflap.c++/pass55-frag.cxx (-O2) (test for excess errors) WARNING: libmudflap.c++/pass55-frag.cxx (-O2) compilation failed to produce executable FAIL: libmudflap.c++/fail24-frag.cxx (-O3) (test for excess errors) WARNING: libmudflap.c++/fail24-frag.cxx (-O3) compilation failed to produce executable FAIL: libmudflap.c++/pass27-frag.cxx (-O3) (test for excess errors) WARNING: libmudflap.c++/pass27-frag.cxx (-O3) compilation failed to produce executable FAIL: libmudflap.c++/pass28-frag.cxx (-O3) (test for excess errors) WARNING: libmudflap.c++/pass28-frag.cxx (-O3) compilation failed to produce executable FAIL: libmudflap.c++/pass31-frag.cxx (-O3) (test for excess errors) WARNING: libmudflap.c++/pass31-frag.cxx (-O3) compilation failed to produce executable FAIL: libmudflap.c++/pass41-frag.cxx (-O3) (test for excess errors) WARNING: libmudflap.c++/pass41-frag.cxx (-O3) compilation failed to produce executable FAIL: libmudflap.c++/pass55-frag.cxx (-O3) (test for excess errors) WARNING: libmudflap.c++/pass55-frag.cxx (-O3) compilation failed to produce executable FAIL: ctors-1 compilation FAIL: ctors-2 compilation FAIL: ctors-12 linkage FAIL: ctors-21 linkage WARNING: program timed out. FAIL: ctors-12 execution WARNING: program timed out. FAIL: ctors-21 execution FAIL: ctors-1 compilation -static FAIL: ctors-2 compilation -static FAIL: ctors-12 linkage -static FAIL: ctors-21 linkage -static WARNING: program timed out. FAIL: ctors-12 execution -static WARNING: program timed out. FAIL: ctors-21 execution -static FAIL: ctors-1 compilation -O2 FAIL: ctors-2 compilation -O2 FAIL: ctors-12 linkage -O2 FAIL: ctors-21 linkage -O2 WARNING: program timed out. FAIL: ctors-12 execution -O2 WARNING: program timed out. FAIL: ctors-21 execution -O2 FAIL: ctors-1 compilation -O3 FAIL: ctors-2 compilation -O3 FAIL: ctors-12 linkage -O3 FAIL: ctors-21 linkage -O3 WARNING: program timed out. FAIL: ctors-12 execution -O3 WARNING: program timed out. FAIL: ctors-21 execution -O3 === libmudflap Summary === # of expected passes1212 # of unexpected failures48 Compiler version: 4.0.0 20050418 (prerelease) Platform: x86_64-unknown-linux-gnu conf
[Bug middle-end/21085] [4.0/4.1 Regression] Virtual memory exhausted with g++
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-18 20:15 --- Created an attachment (id=8678) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8678&action=view) Don't alter overflowed constants sign_bit_p returns false for overflowed constants, this is bad for this testcase. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |phython at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21085
[Bug c++/17445] too few template-parameter-lists
--- Additional Comments From bangerth at dealii dot org 2005-04-18 20:16 --- This code has at least two bugs: template class MyType; template <> std::map MyType::m_map; First, the instantiation must come *after* the definition of the static member. Second, the definition you thought you have written is in fact only the declaration of an explicit specialization of that member. It needs an initializer. You need to write template <> std::map MyType::m_map = std::map(); W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
[Bug c++/21092] friend inaccessibility
--- Additional Comments From kreckel at ginac dot de 2005-04-18 20:19 --- (In reply to comment #1) > No, the code is invalid, as Y has not been interjected yet. This is a progression and not a regression. Really? What about paragraph 11.4/7 "A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092