[Bug libfortran/19216] list directed read with leading slash (NIST FM923)

[cvs-commit at gcc dot gnu dot org]

--- 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)

[fxcoudert at gcc dot gnu dot org]

--- 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

[cvs-commit at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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

[falk at debian dot org]

--- 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

[adah at netstd dot com]

--- 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

[giovannibajo at libero dot it]

--- 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

[ebotcazou at gcc dot gnu dot org]

--- 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

[rakdver at gcc dot gnu dot org]

--- 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

[jsm28 at gcc dot gnu dot org]

--- 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

[sstrasser at systemhaus-gruppe dot de]

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

[jsm28 at gcc dot gnu dot org]

--- 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"

[fxcoudert at gcc dot gnu dot org]

--- 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

[sstrasser at systemhaus-gruppe dot de]

--- 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

[matz at suse dot de]

-- 
   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

[sstrasser at systemhaus-gruppe dot de]

--- 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

[matz at suse dot de]

--- 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

[matz at suse dot de]

--- 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

[fxcoudert at gcc dot gnu dot org]

--- 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++

[strieder at informatik dot uni-kl dot de]

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

[leslie dot barnes at amd dot com]

--- 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

[pcarlini at suse dot de]

--- 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.

[kazu at cs dot umass dot edu]

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

[matz at suse dot de]

--- 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

[pcarlini at suse dot de]

--- 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

[pinskia at gcc dot gnu dot org]

-- 
   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

[pinskia at gcc dot gnu dot org]

-- 
   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

[pinskia at gcc dot gnu dot org]

-- 
   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

[mmitchel at gcc dot gnu dot org]

--- 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

[sstrasser at systemhaus-gruppe dot de]

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

[matz at suse dot de]

--- 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

[sstrasser at systemhaus-gruppe dot de]

--- 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

[mckinlay at redhat dot com]

--- 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

[kazu at cs dot umass dot edu]

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

[cvs-commit at gcc dot gnu dot org]

--- 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

[phython at gcc dot gnu dot org]

--- 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)

[phython at gcc dot gnu dot org]

-- 
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

[pinskia at gcc dot gnu dot org]

-- 
   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

[hjl at lucon dot org]

-- 
   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

[pinskia at gcc dot gnu dot org]

--- 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

[cvs-commit at gcc dot gnu dot org]

--- 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

[dpatel at apple dot com]

--- 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

[matz at suse dot de]

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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[kazu at cs dot umass dot edu]

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

[matz at suse dot de]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[matz at suse dot de]

--- 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

[mmitchel at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[carlos at mind dot be]

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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[carlos at mind dot be]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[carlos at mind dot be]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[jason at redhat dot com]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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.

[pinskia at gcc dot gnu dot org]

--- 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

[sabre at nondot dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

-- 
   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

[pinskia at gcc dot gnu dot org]

--- 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.

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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++

[pinskia at gcc dot gnu dot org]

--- 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++

[pinskia at gcc dot gnu dot org]

-- 
   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++

[pinskia at gcc dot gnu dot org]

--- 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++

[pinskia at gcc dot gnu dot org]

--- 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

[schlie at comcast dot net]

--- 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

[schlie at comcast dot net]

--- 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

[Ralf dot Wildenhues at gmx dot de]

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++

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

--- 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

[pinskia at gcc dot gnu dot org]

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

[laurent at guerby dot net]

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++

[phython at gcc dot gnu dot org]

--- 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

[bangerth at dealii dot org]

--- 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

[kreckel at ginac dot de]

--- 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