[Bug c++/18835] memory consumption is high for C++ testcase

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||23044


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18835

[Bug c++/23044] New: [4.0/4.1 Regression] ICE on vaild code

[pinskia at gcc dot gnu dot org]

This is reduced from PR 14719/18835:
struct no_context {
  template< class Event > void no_function( const Event & );
};
template< class Event, class Destination, class TransitionContext = no_context,
void ( TransitionContext::*pTransitionAction )( const Event & ) = 
&no_context::no_function< Event > >
struct transition
{
  struct EvFlipBit {};
  struct BitState{};
  template< class BitNo, class StateNo > struct FlipTransition {
typedef transition type;
  };
};

-- 
   Summary: [4.0/4.1 Regression] ICE on vaild code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: c++
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
OtherBugsDependingO 18835
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044

[Bug c++/23044] [4.0/4.1 Regression] ICE on vaild code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044

[Bug c++/23045] New: ICE in force_decl_die, at dwarf2out.c:12621

[dank at kegel dot com]

In testing gcc-4.1-20050716 for i686:

I originally ran into the following error

  internal compiler error: tree check: expected tree that contains 'decl
minimal' structure, have 'record_type'  in lookup_decl_die, at dwarf2out.c:5461

on the last line of a program.  While starting to come up with
a minimal test case, I was surprised to find that although
I could reproduce that error with preprocessed source,
stripping out the lines starting with # produced a different error:

x.ii: In instantiation of '__gnu_cxx::rope >':
x.ii:42429:   instantiated from here
x.ii:41107: internal compiler error: in force_decl_die, at dwarf2out.c:12621

This is probably fortunate, since it now dies much sooner than at the
end of the program.  

To reproduce this, unpack http://kegel.com/gcc/ice-rope.ii.gz,
then compile it with

i686-unknown-linux-gnu-gcc -g -Wall -Werror -funsigned-char -c

Apologies for not finding a small testcase,
and for using a week-old snapshot for testing.
Hopefully this is useful anyway.

-- 
   Summary: ICE in force_decl_die, at dwarf2out.c:12621
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045

[Bug c++/23046] New: ICE in set_value_range, at tree-vrp.c:191

[dank at kegel dot com]

While testing gcc-4.1-20050716, I ran across the error

bar.cc: In static member function 'static std::string
Blort::ConstructFullName(const std::string&, const std::vector >*, const std::string&, Blort::TwoValuedEnumType)':
bar.cc:1214: internal compiler error: in set_value_range, at tree-vrp.c:191

This was reproducible with just -O2; no other compiler flags were needed
to get the ICE.  (-O wasn't enough.)

It might be hard to provide a sanitized testcase,
but I can try if that's needed to track this down.

-- 
   Summary: ICE in set_value_range, at tree-vrp.c:191
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046

[Bug libstdc++/22634] partial_sum is too constrained

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-07-24 09:06 
---
Ok, let's suspend it for now: in the meanwhile I checked that at least another
implementation behaves exactly like GCC, another good reason to wait for 
feedback
from the committee before taking any action.

Gaby, maybe adjacent_difference should also be in the DR?

-- 
   What|Removed |Added

 CC||gdr at integrable-solutions
   ||dot net
 Status|REOPENED|SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634

[Bug tree-optimization/22526] vectorizer produces mis-match types in conditionals

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-24 
10:11 ---
Subject: Bug 22526

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-24 10:10:54

Modified files:
gcc: ChangeLog tree-vectorizer.c 

Log message:
PR tree-optimization/22526
* tree-vectorizer.c (slpeel_tree_peel_loop_to_edge): Match the type
of the zero node.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9529&r2=2.9530
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vectorizer.c.diff?cvsroot=gcc&r1=2.103&r2=2.104



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22526

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-07-24 10:11 
---
(In reply to comment #6)
> (In reply to comment #5) 
> > Bootstraped completed on x86_64-linux for 
> > LAST_UPDATED Sat Jul 23 17:57:57 UTC 2005 
> > with Andrew's patch. 
>  
> have You done a full `make bootstrap` ? 
> on my snapshot (20050723T1611UTC) i get an ice with Andrew's patch. 
> without Andrew's patch full boostrap works fine. 
> i have no idea what's wrong :| 
  
Yes I always start everything from scratch and configure prefix to an empty
directory (in fact I use a script that does everything).

My testresults (with configure line) are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01266.html

I'm attaching my current diff so you can check.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-07-24 10:12 
---
Created an attachment (id=9341)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9341&action=view)
Current diff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[pluto at agmk dot net]

--- Additional Comments From pluto at agmk dot net  2005-07-24 10:33 ---
(In reply to comment #14) 
> (In reply to comment #6) 
> > (In reply to comment #5)  
> > > Bootstraped completed on x86_64-linux for  
> > > LAST_UPDATED Sat Jul 23 17:57:57 UTC 2005  
> > > with Andrew's patch.  
> >   
> > have You done a full `make bootstrap` ?  
> > on my snapshot (20050723T1611UTC) i get an ice with Andrew's patch.  
> > without Andrew's patch full boostrap works fine.  
> > i have no idea what's wrong :|  
>
> Yes I always start everything from scratch and configure prefix to an empty 
> directory (in fact I use a script that does everything). 
>  
> My testresults (with configure line) are here: 
> http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01266.html 
>  
> I'm attaching my current diff so you can check. 
 
Your patch is different from patch linked in PR22533. 
I'm testing Your patch now... 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

[Bug fortran/17123] Assertion fail in trans-const.c

[refson dot temp at ntlworld dot com]

--- Additional Comments From refson dot temp at ntlworld dot com  
2005-07-24 10:36 ---
Please accept my apologies.  I had not realised that this was a
gcc-developers-only site and that bug reports from users are not
welcome.  I have no expertise in compiler development so the
likelyhood of my being able to fix this myself is small.  

Your suggestion of paying someone to fix it is interesting, but if, 
as you say there are many similar bugs I fear that this would be a 
poor investment compared to paying for one of the several available
commercial compilers (eg the Intel one which is very reasonably priced)
in which case I could be reasonably sure of being able to compile my code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17123

[Bug libstdc++/22634] partial_sum is too constrained

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-07-24 11:35 ---
Subject: Re:  partial_sum is too constrained

"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:

| Gaby, maybe adjacent_difference should also be in the DR?

yes, you're right.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634

[Bug c++/22635] OVERLOAD should not be a linked list of trees

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-07-24 
12:40 ---
Can you measure how much memory do all the overload nodes take in the big 
testcases? Theoretically, an OVERLOAD could measure 8 bytes or so (on 32 bit 
systems). So we currently waste more than 100 bytes per each node, but if there 
are not so many of them it is not important.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22635

[Bug tree-optimization/23046] ICE in set_value_range, at tree-vrp.c:191

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |tree-optimization
   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046

[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|ICE in set_value_range, at  |[4.1 Regression] ICE in
   |tree-vrp.c:191  |set_value_range, at tree-
   ||vrp.c:191
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046

[Bug c++/22635] OVERLOAD should not be a linked list of trees

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
13:23 ---
PR 12850 has the numbers.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22635

[Bug c++/23045] ICE in force_decl_die, at dwarf2out.c:12621

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
13:25 ---
lookup_decl_die is most likely PR 22034.
force_decl_die is most likely PR 22514.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045

[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
13:37 ---
Hmm, nothing can be done without a testcase.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046

[Bug rtl-optimization/23047] New: Combine ignores flag_wrapv

[phython at gcc dot gnu dot org]

The following testcase aborts with gcc 3.4, 4.0 and 4.1 when optimizing.  It
looks like combine is removing the condition here.
#include 

void abort ();
void exit (int);

void f (int a) {
if (abs(a) < 0)
  return;
abort ();
}

int main (int argc, char *argv[]) {
f (INT_MIN);
exit (0);
}

-- 
   Summary: Combine ignores flag_wrapv
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phython at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047

[Bug rtl-optimization/23047] Combine ignores flag_wrapv

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
13:57 ---
Confirmed.  Note this is does not effect i686 because on i686 we expand abs 
right away.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-07-24 13:57:36
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047

[Bug rtl-optimization/23047] Combine ignores flag_wrapv

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
14:01 ---
Caused by:

2002-07-20  Roger Sayle  <[EMAIL PROTECTED]>

* simplify-rtx.c (simplify_relational_operation): Optimize
abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).
This was introduced before -fwrapv was introduced.

-- 
   What|Removed |Added

 CC||roger at eyesopen dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047

[Bug c++/23044] [4.0/4.1 Regression] ICE on vaild code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
14:06 ---
This was working on 20041124 but failing with 20050225.

Here is something a little smaller:
struct no_context {
  template< class Event > void no_function( const Event & );
};
template< class Event, class TransitionContext = no_context,
void ( TransitionContext::*pTransitionAction )( const Event & ) = 
&no_context::no_function< Event > >
struct transition
{
  struct EvFlipBit {};
  typedef transition type;
};

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044

[Bug tree-optimization/23048] New: Segfault with -O1 -ftree-vectorize on 4.1.x

[drab at kepler dot fjfi dot cvut dot cz]

The example (attached below), when compiled by following gcc

---
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20050723/gcc-CVS-20050723/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/gcc-4.1 --sysconfdir=/etc
--libdir=/usr/local/opt/gcc-4.1/lib --libexecdir=/usr/local/opt/gcc-4.1/libexec
--sharedstatedir=/var --localstatedir=/var --program-suffix=-4.1
--with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib
--enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs
--enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage
--disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath
--enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization
--with-system-zlib --with-libbanshee --with-demangler-in-ld
--with-arch=athlon-xp --enable-libada --enable-languages=c,c++,f95,objc,ada
Thread model: posix
gcc version 4.1.0 20050723 (experimental)
-

with

-
gcc -O1 -ftree-vectorize -c -o envsubst-envsubst.o envsubst-envsubst.c
-

results in this:

-
envsubst.c: In function ‘find_variables’:
envsubst.c:234: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
-

Tested on both i686-pc-linux-gnu and x86_64-pc-linux-gnu with the same result.

gcc version 4.0.1 20050630 (prerelease) seems to take it without problems.

-- 
   Summary: Segfault with -O1 -ftree-vectorize on 4.1.x
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug tree-optimization/23048] Segfault with -O1 -ftree-vectorize on 4.1.x

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-07-24 14:10 ---
Created an attachment (id=9342)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9342&action=view)
Triggers the bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug tree-optimization/23048] Segfault with -O1 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
 GCC target triplet||i?86-*-*, x86_64-*-*
   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug tree-optimization/23048] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
14:13 ---
Reducing.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
Summary|Segfault with -O1 -ftree-   |ICE in get_loop_body with -
   |vectorize on 4.1.x  |O1 -ftree-vectorize on 4.1.x


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug c++/23044] [4.0/4.1 Regression] ICE on vaild code

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-07-24 14:15 ---
Confirmed, introduced between "2005-01-07 00:20 UTC" and "2005-01-08 00:20 UTC".

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-07-24 14:15:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044

[Bug c++/23044] [4.0/4.1 Regression] ICE on vaild code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
14:19 ---
Caused by:
+2005-01-07  Nathan Sidwell  <[EMAIL PROTECTED]>
+
+   PR c++/19298
+   * pt.c (tsubst_qualified_id): Call convert_from_reference.
+

-- 
   What|Removed |Added

 CC||nathan at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044

[Bug tree-optimization/23049] New: ICE with -O3 -ftree-vectorize on 4.1.x

[drab at kepler dot fjfi dot cvut dot cz]

The example (attached below), when compiled by following gcc

---
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20050723/gcc-CVS-20050723/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/gcc-4.1 --sysconfdir=/etc
--libdir=/usr/local/opt/gcc-4.1/lib --libexecdir=/usr/local/opt/gcc-4.1/libexec
--sharedstatedir=/var --localstatedir=/var --program-suffix=-4.1
--with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib
--enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs
--enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage
--disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath
--enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization
--with-system-zlib --with-libbanshee --with-demangler-in-ld
--with-arch=athlon-xp --enable-libada --enable-languages=c,c++,f95,objc,ada
Thread model: posix
gcc version 4.1.0 20050723 (experimental)
-

with

-
gcc -O3 -ftree-vectorize -c -o ac3enc.o ac3enc.c
-

results in this:

-
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
-

Tested on both i686-pc-linux-gnu and x86_64-pc-linux-gnu with the same result.

With -O2 -ftree-vectorize it compiles without problem.
Also gcc version 4.0.1 20050630 (prerelease) seems to take it without problems.

-- 
   Summary: ICE with -O3 -ftree-vectorize on 4.1.x
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i?86-*-*, x86_64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] ICE with -O3 -ftree-vectorize on 4.1.x

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-07-24 14:23 ---
Created an attachment (id=9343)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9343&action=view)
Triggers the problem


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] ICE with -O3 -ftree-vectorize on 4.1.x

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-07-24 14:24 ---
It doesn't seem to be related to the Bug 23048 to me, so i reported it 
separately.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] ICE with -O3 -ftree-vectorize on 4.1.x

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-07-24 14:32 ---
Created an attachment (id=9344)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9344&action=view)
Seems to trigger the same problem

The behaviour is exactly the same as with my first example, so I'm adding this
just for completness. Although, it could also be a different bug that just
gives the same visible result for me.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
14:35 ---
Confirmed, reduced testcase:
void find_variables (const char *string)
{
  char c;
  do c = *++string;
  while ((c >= 'A' && c <= 'Z') || (c >= 'a' && c <= 'z') || c == '_');
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.1.0
  Known to work||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-07-24 14:35:23
   date||
Summary|ICE in get_loop_body with - |[4.1 Regression] ICE in
   |O1 -ftree-vectorize on 4.1.x|get_loop_body with -O1 -
   ||ftree-vectorize on 4.1.x
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug tree-optimization/23049] ICE with -O3 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
14:57 ---
Reducing the first one.  It is a stack overflow.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|critical|normal
   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-07-24 15:06 ---
Introduced between "2005-04-09 00:20 UTC" and "2005-04-10 00:20 UTC"

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
15:09 ---
Looks like it was caused by:
+2005-04-08  Diego Novillo  <[EMAIL PROTECTED]>
+
+   Merge from tree-cleanup-branch: VRP, store CCP, store
+   copy-prop, incremental SSA updating of FUD chains and
+   newly exposed symbols.
+

-- 
   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[pluto at agmk dot net]

--- Additional Comments From pluto at agmk dot net  2005-07-24 15:10 ---
with pinskia1.patch bootstrap gcc doesn't ice. 
patch linked to PR22533 causes an ice. 
 
/close. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

Re: [Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[Andrew Pinski]

> 
> 
> --- Additional Comments From pluto at agmk dot net  2005-07-24 15:10 
> ---
> with pinskia1.patch bootstrap gcc doesn't ice. 
> patch linked to PR22533 causes an ice. 

Guess I have to fix that then :(.

-- Pinski

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2005-07-24 
15:13 ---
Subject: Re:  ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

> 
> 
> --- Additional Comments From pluto at agmk dot net  2005-07-24 15:10 
> ---
> with pinskia1.patch bootstrap gcc doesn't ice. 
> patch linked to PR22533 causes an ice. 

Guess I have to fix that then :(.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.1.0
  Known to work||4.0.0
Summary|ICE with -O3 -ftree-|[4.1 Regression] ICE with -
   |vectorize on 4.1.x  |O3 -ftree-vectorize on 4.1.x


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
15:37 ---
Reduced testcase for the first one:
static unsigned short int crc_table[256];
void AC3_encode_init(void)
{
  unsigned int c, n, k;
  for(n=0;  n<256; n++)
  {
c = n << 8;
for (k = 0; k < 8; k++)
{
  if (c & (1 << 15))
   c = ((c << 1) & 0x) ^ (((1 << 0) | (1 << 2) | (1 << 15) | (1 << 16)) 
& 0x);
}
crc_table[n] = c;
  }
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-07-24 15:37:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
15:40 ---
Note the backtrace is:
#5211 0x003f58d0 in fold_ternary (code=COND_EXPR, type=0x1e0e5b0, 
op0=0x1ee9d50, 
op1=0x1e18200, op2=0x1ee2080) at ../../gcc/fold-const.c:9905
#5212 0x003f8368 in fold_build3 (code=COND_EXPR, type=0x1e0e5b0, op0=0x1ee9d50, 
op1=0x1e18200, op2=0x1ee2080) at ../../gcc/fold-const.c:10375
#5213 0x003bb030 in fold_cond_expr_with_comparison (type=0x1e0e5b0, 
arg0=0x1ee9d50, 
arg1=0x1e18200, arg2=0x1ee2080) at ../../gcc/fold-const.c:4

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-07-24 15:43 ---
(In reply to comment #5)
> Reduced testcase for the first one:

introduced between "2005-05-17 00:20 UTC" and "2005-05-18 00:20 UTC"

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
15:56 ---
The reduced testcase for the second one:
unsigned long CRCTab[256];
void InitCRC(void) {
  int I, J;
  unsigned long C;
  for (I=0; I<256; I++)
  {
for (C=I,J=0;J<8;J++)
  C=(C & 1) ? (C>>1)^0xEDB88320L : (C>>1);
CRCTab[I]=C;
  }
}


They do look like the same bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug c++/23042] This is the first, two similar incidents followed which are probably related.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
16:01 ---
You need to use the full comand line to reproduce the failure you are getting.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23042

[Bug target/23043] [4.1 regression] [m68k-linux] bootstrap error on m68k-linux

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build, ice-on-valid-code
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23043

[Bug tree-optimization/22591] [4.0 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
16:04 ---
This is a strict aliasing bug.

-- 
   What|Removed |Added

  Component|c++ |tree-optimization
   Keywords||alias


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-07-24 16:13 ---
(In reply to comment #8)
> The reduced testcase for the second one:
to make it fail on amd64 one needs to change long -> int. and this testcase
started to fail at the same time as testcase in comment #5 .

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049

[Bug rtl-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
16:15 ---
Hmm, this test does not fail on ppc-darwin but does on i686-pc-linux-gnu.

I think this is a RTL problem as the tree dumps for both i686 and ppc are the 
same at -O2.

Then again this might be a bug in the C++ front-end still.

-- 
   What|Removed |Added

  Component|tree-optimization   |rtl-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
16:25 ---
Actually I take that back.
the tree dumps are different.
Hmm, maybe we are miscompiling more than just the testcase.

-- 
   What|Removed |Added

  Component|rtl-optimization|tree-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
16:33 ---
(In reply to comment #22)
> Hmm, maybe we are miscompiling more than just the testcase.
Nope.  Compiling for x86_64 from ppc-darwin, we get the same failure here.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug libstdc++/22634] partial_sum is too constrained

[squell at alumina dot nl]

--- Additional Comments From squell at alumina dot nl  2005-07-24 16:42 
---
(In reply to comment #7)

> Yes, the standard requirements for iterators exhibit inconsistencies
> at many places; for example an InputIterator is not required (by the
> Standard) to be copy-constructible; consequently it cannot be used as
> function parameter type.  

Yes, I noticed the standard isn't explicit about that, but isn't
that requirement implied in the semantics for '*r++'?

I read somewhere the LWG believed the requirement to be implicit.
(found: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241)

> BAck to the issue of this PR; I think there is way too vagueness in
> the standard and the "obvious" thing to do is to use the natural type
> of the intermediate results.  However, we may actually want to submit
> a DR (I'll do it).  I would suggest this issue be suspended in the
> meantime.

I agree the paragraph should probably make it explicit what type is being
used. I think there's another subtle error in the Effects clause, since 
dereferencing an input iterator invalidates previous copies, and order of
evaluation is unspecified.

I noticed this also happens in unique_copy. It works on Input Iterators but
its semantics are specified in terms of '*i == *(i-1)' or 'pred(*i, *(i-1))'.

Perhaps this should be part of the DR, or a seperate one?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634

[Bug libstdc++/22634] partial_sum is too constrained

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-07-24 17:18 ---
Subject: Re:  partial_sum is too constrained

"squell at alumina dot nl" <[EMAIL PROTECTED]> writes:

| --- Additional Comments From squell at alumina dot nl  2005-07-24 16:42 
---
| (In reply to comment #7)
| 
| > Yes, the standard requirements for iterators exhibit inconsistencies
| > at many places; for example an InputIterator is not required (by the
| > Standard) to be copy-constructible; consequently it cannot be used as
| > function parameter type.  
| 
| Yes, I noticed the standard isn't explicit about that,

Oh, the standard is quite explicit about that.  Look up the
requirement table input iterators and compare it with other iterators.

| but isn't
| that requirement implied in the semantics for '*r++'?

No.

| I read somewhere the LWG believed the requirement to be implicit.
| (found: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241)

No, that is issue is different.  I'm talking about the
copy-construction of the iterator itself; you're talking about the
copy-construction of the value_type.  Not the same thing.

| > BAck to the issue of this PR; I think there is way too vagueness in
| > the standard and the "obvious" thing to do is to use the natural type
| > of the intermediate results.  However, we may actually want to submit
| > a DR (I'll do it).  I would suggest this issue be suspended in the
| > meantime.
| 
| I agree the paragraph should probably make it explicit what type is being
| used. I think there's another subtle error in the Effects clause, since 
| dereferencing an input iterator invalidates previous copies, and order of
| evaluation is unspecified.
| 
| I noticed this also happens in unique_copy. It works on Input Iterators but
| its semantics are specified in terms of '*i == *(i-1)' or 'pred(*i, *(i-1))'.
| 
| Perhaps this should be part of the DR, or a seperate one?

It should probably be a separate one.  Thanks!

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
17:26 ---
Note this works just fine on ppc-darwin with my patch so I don't know what is 
going on.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

[Bug c++/23045] ICE in force_decl_die, at dwarf2out.c:12621

[dank at kegel dot com]

--- Additional Comments From dank at kegel dot com  2005-07-24 17:28 ---
Yep.  

Compiling PR22034's testcase yields
pr22034.cc:6: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'record_type'  in lookup_decl_die, at
dwarf2out.c:5461

And compiling pr22514's testcase yields
pr22514.cc:11: error: expected unqualified-id before '}' token
pr22514.cc: In instantiation of 's::list<1>':
pr22514.cc:12:   instantiated from here
pr22514.cc:8: internal compiler error: in force_decl_die, at dwarf2out.c:12621

So this is a dup.  Sorry for the noise.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045

[Bug c++/23045] ICE in force_decl_die, at dwarf2out.c:12621

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
17:29 ---


*** This bug has been marked as a duplicate of 22034 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045

[Bug c++/22034] [4.1 Regression], ICE on valid, dwarf2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
17:29 ---
*** Bug 23045 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||dank at kegel dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034

[Bug c++/20724] function overload resolution fails when any template is declared

[kjd at duda dot org]

--- Additional Comments From kjd at duda dot org  2005-07-24 17:33 ---
I will admit I've had difficulty understanding the interaction between scope 
searching and overload resolution, but I cannot believe gcc is handling this 
right.  Consider the example program:

/* 1 */   namespace N {
/* 2 */   int foo ( char * ) { return 200; }
/* 3 */   template< typename T > int foo();
/* 4 */   }
/* 5 */   enum Enum { enum1 };
/* 6 */   int foo( Enum const & ) { return 100; }
/* 7 */   int main() {
/* 8 */  using N:: foo;
/* 9 */  foo( enum1 );
/* 10 */  }

When resolving the call on line 9, either gcc should search the root namespace 
or it should stop after finding "foo" in namespace N.  Whether it searches the 
root namespace should not depend on whether or not one of the overloads in 
namespace N is a template.  Yet with gcc, the program compiles when line 3 is 
commented out, and fails to compile when line 3 is included.  You can add more 
non-matching foo()'s to namespace N, and the program continues to compile, as 
long as none of them is a template.

If Wolfgang's logic in comment 2 were right, then this program would not 
compile:

namespace N {
int foo ( char * ) { return 200; }
int foo() { return 300; }
int foo( int, int ) { return 400; }
}
enum Enum { enum1 };
int foo( Enum const & ) { return 100; }
int main() {
   using N:: foo;
   foo( enum1 );
}

but in fact, it does.

-Ken


(In reply to comment #2)
> gcc is actually correct. Per the using declaration in main(), you 
> introduce N::foo into the scope of foo(), and when foo(enum1) is called 
> we find the name foo inside namespace N and then stop to search, so ::foo 
> isn't found in any case. 
>  
> What then happens is this: gcc has one non-template and one template, none 
> of which match the function argument, so it says that there is no matching 
> function. 
>  
> W. 



-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724

[Bug SWING/22617] reopen 13414: ImageIcon("") throws IllegalArgumentException

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
17:57 ---


*** This bug has been marked as a duplicate of 22979 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22617

[Bug c++/20724] function overload resolution fails when any template is declared

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
18:02 ---
Both ICC and Comeau accept this.

-- 
   What|Removed |Added

 Status|REOPENED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724

[Bug c++/20724] function overload resolution fails when any template is declared

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-07-24 18:21 ---
Subject: Re:  function overload resolution fails when any template is declared

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| Both ICC and Comeau accept this.

just a note that since ICC and como are now using the same brand of
front-ends, it may indeed seem strange if they did not agree :-p

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724

[Bug libgcj/14696] URL constructor incorrectly causes file canonicalization

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-07-24 
19:27 ---
This is fixed in 4.0 and on cvs head.
Now we do textual canonicalization, and we don't use the filesystem.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14696

[Bug libgcj/16229] [meta-bug] http, URL, and URLConnection issues

[tromey at gcc dot gnu dot org]

-- 
Bug 16229 depends on bug 14696, which changed state.

Bug 14696 Summary: URL constructor incorrectly causes file canonicalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14696

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16229

[Bug libgcj/20169] Serialization: readResolve does not work

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-07-24 
19:36 ---
Note that this is fixed in Classpath but not in libgcj as
we still have divergences in serialization.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-07-24 19:36:35
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169

[Bug libgcj/20198] java.security.CodeSource.getLocation output is different than expected

[green at redhat dot com]

--- Additional Comments From green at redhat dot com  2005-07-24 19:49 
---
Created an attachment (id=9352)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9352&action=view)
Proposed patch

This patch makes your test program emit an absolute path.

I'm not sure it's 100% correct.  For instance, perhaps we should canonicalize
the path in addition to makeing it absolute.  Also, perhaps this should happen
in URLClassLoader instead of the system loader.  Hopefully a discussion will
happen on this thread:

http://gcc.gnu.org/ml/java-patches/2005-q3/msg00144.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20198

[Bug tree-optimization/22623] [4.1 Regression] type mismatch between an SSA_NAME and its symbol

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
22:01 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22623

[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-07-24 
22:29 ---
Just another data point: The problem disappeared on mainline with
Dan's patch
http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg01108.html


-- 
   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
22:32 ---
(In reply to comment #25)
> Just another data point: The problem disappeared on mainline with
> Dan's patch

Not according to my testing, it still fails on the mainline as of today.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug rtl-optimization/23047] Combine ignores flag_wrapv

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-07-24 
22:38 ---
Created an attachment (id=9353)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9353&action=view)
Honour flag_wrapv


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

Re: Internal compiler error

[Andrew Pinski]

> 
> This is a multi-part message in MIME format.
> 
> --=_NextPart_000_0035_01C5906D.A0EF4EC0
> Content-Type: text/plain;
>   charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> 
> GCC Version: 4.0.1
> System Type: Windows ME
> Options given when GCC was configured/built: arm-elf-gcc -v
> Complete command line that triggers the bug:
> 
> arm-elf-gcc  -O2 -marm -march=armv4t -mtune=arm920t -mapcs -fomit-frame-poin
> ter -fshort-enums -ffast-math -fshort-double -mstructure-size-boundary=32 -m
> no-thumb -interwork -I/c/gamepark_sdk/include -Wno-multichar -save-temps  -c
> wl_menu.c -o  wl_menu.o
> 
> Compiler Output:
> 
> wl_menu.c: In function 'WaitKeyUp':
> wl_menu.c:3028: internal compiler error: in c_common_type, at c-typeck.c:530
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> MAKE: *** [wl_menu.o] Error 1
> 
> And I have included the .i file relevant.

This is PR 22311: .

Thanks,
Andrew Pinski

[Bug middle-end/22287] [4.1 Regression] gcc.c-torture/execute/simd-2.c fails (simd-1.c too for some).

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-24 
22:53 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22287

[Bug tree-optimization/22493] [4.1 Regression] with -fwrapv -INT_MIN is still not positive

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
00:11 ---
Patch posted here: .

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||07/msg01566.html
   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22493

[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-07-25 
00:15 ---
> Not according to my testing, it still fails on the mainline as of today.

Indeed, I have to add -march=pentium4 to trigger the bug, though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591

[Bug bootstrap/22440] make install fails with --enable-bootstrap

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-07-25 00:26 ---
Fixed by:

2005-07-24  Paolo Bonzini  <[EMAIL PROTECTED]>

* Makefile.tpl: Wrap install between unstage and stage
* Makefile.in: Regenerate.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22440

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-07-25 
00:35 ---
Calling vrp_evaluate_condition with use_equiv_p = false in tree-ssa-propagate.c
could fix this problem.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22630

[Bug other/22631] ICE / ada / error in gimple_add_tmp_var, at gimplify.c:557

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
00:43 ---
Oh, If I change the second agrument to create_tmp_var/create_tmp_var_raw to "C" 
instead of NULL, we 
no longer get an ICE.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22631

[Bug c++/22545] [3.4/4.0/4.1 Regression] ICE with pointer to class member & user defined conversion operator

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22545

[Bug c++/23051] New: weird include path?

[andre dot maute at gmx dot de]

Suppose you have the following bash script called  memory  in your current  
directory  
  
 memory ---  
#/bin/sh  
 memory ---  
  
and the following mini C++ file  
  
 hello.cxx -  
#include   
 hello.cxx -  
  
calling now  
g++ -I . hello.cxx -c  
  
the compiler will print MANY errors.  
it looks like it will include the local file  memory  
  
Shouldn't  include the shipped ?  
 
Regards Andre

-- 
   Summary: weird include path?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot maute at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23051

[Bug c++/23051] weird include path?

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2005-07-25 
01:06 ---
(In reply to comment #0) 
> the compiler will print MANY errors.   
> it looks like it will include the local file  memory   
 
the compiler prints MANY errors.   
it looks like it includes the local file  memory   
 
Sorry 
Andre 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23051

[Bug c++/23051] weird include path?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:10 ---
-I puts the directory at the front of the standard include path.
You want to use -idirafter . instead.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23051

[Bug c/12245] [3.4/4.0/4.1 regression] Uses lots of memory when compiling large initialized arrays

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:27 ---
c-typeck.c:5987 (output_init_element) 0: 0.0%   
23955160:100.0%   22770552:20.9%   
13171408:99.1% 19
convert.c:671 (convert_to_integer) 52184768:37.8%  0: 
0.0%  0: 0.0%  0: 0.0%
1630774
ggc-common.c:193 (ggc_calloc)  33547596:24.3%  0: 
0.0%   33577352:30.7%
544: 0.0% 45
tree.c:828 (build_int_cst_wide)52176864:37.8%  0: 
0.0%   52177536:47.8%  0: 
0.0%3261075


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245

[Bug c/12245] [3.4/4.0/4.1 regression] Uses lots of memory when compiling large initialized arrays

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:30 ---
There must be a better way to add on to celt in output_init_element.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245

[Bug c++/14179] [3.4/4.0/4.1 Regression] out of memory while parsing array with many initializers

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:34 ---
Using the testcase from PR 12245:
cp/parser.c:285 (cp_lexer_new_main)   0: 0.0%  
372302336:88.5%  0: 0.0%  
104391168:79.7%  9
cp/parser.c:270 (cp_lexer_new_main)   0: 0.0% 364288: 
0.1%  0: 0.0% 102144: 
0.1%  1
cp/parser.c:12407 (cp_parser_initializer_list) 22770552:24.8%   23955160: 
5.7%  0: 0.0%   
13171408:10.1% 19
cp/decl.c:4182 (reshape_init_array_1) 0: 0.0%   23955160: 
5.7%   22770552:24.6%   
13171408:10.1% 19
ggc-common.c:193 (ggc_calloc)  16770368:18.3%  0: 
0.0%   16805272:18.1%
612: 0.0% 51
tree.c:828 (build_int_cst_wide) 480: 0.0%  0: 
0.0%   52180672:56.3%  0: 0.0%
1630661
convert.c:671 (convert_to_integer) 52187584:56.8%  0: 
0.0%  0: 0.0%  0: 0.0%
1630862


This is worse than the C front-end.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179

[Bug gcov/profile/23052] New: return of class object sometimes reported as uncovered code

[jbuck at gcc dot gnu dot org]

With the attached test case, do

% g++ -ftest-coverage -fprofile-arcs covbug.cpp -o covbug
% ./covbug
% gcov covbug.cpp

There will be two lines flagged as uncovered:

% grep '' covbug.cpp.gcov
#:   29:m_bits = new unsigned[nw];
#:   37:  return result;

The first is expected, the second is wrong.  I repeatedly see
errors of this type, where a return of a class object is flagged as
not covered.  Either a "-" (indicating that no code is present) or an
execution count would be acceptable, but putting out # indicating
uncovered source code is a bug.

-- 
   Summary: return of class object sometimes reported as uncovered
code
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gcov/profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbuck at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23052

[Bug gcov/profile/23052] return of class object sometimes reported as uncovered code

[jbuck at gcc dot gnu dot org]

--- Additional Comments From jbuck at gcc dot gnu dot org  2005-07-25 01:40 
---
Created an attachment (id=9355)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9355&action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23052

[Bug c++/19614] Excessive memory consumption with a class with large (200) virtual (pure?) function and derived classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:40 ---
cp/parser.c:285 (cp_lexer_new_main)   0: 0.0%   
22585856:63.1%  0: 0.0%
6332928:24.0%  5
tree.c:966 (build_constructor_from_list)  28488: 0.0%  0: 
0.0%   38444792:40.2%
9123452:34.6%   7212
cp/decl.c:11123 (cxx_push_function_context)  396000: 0.2%  0: 
0.0% 147600: 0.2%  
65232: 0.2%   5436
cp/pt.c:5954 (tsubst_template_args)  449196: 0.2%  0: 
0.0% 115304: 0.1%  31156: 
0.1%  18671
cp/decl.c:533 (poplevel) 390540: 0.2%  0: 
0.0% 178440: 0.2%  75864: 0.3%   
9483
cp/class.c:7042 (dfs_accumulate_vtbl_inits)  107680: 0.0%  0: 
0.0% 480640: 0.5%  0: 
0.0%  18385
tree.c:3643 (build_distinct_type_copy)69888: 0.0%  0: 
0.0% 532608: 0.6%  0: 
0.0%   6276
cp/method.c:131 (make_thunk)  0: 0.0%  0: 
0.0% 605200: 0.6%  35600: 
0.1%   4450
tree.c:607 (copy_list) 1408: 0.0%  0: 
0.0% 622904: 0.7%  0: 0.0%  
11501
c-semantics.c:120 (build_stmt)   436032: 0.2%  0: 
0.0% 221680: 0.2%   2116: 
0.0%  18967
cp/class.c:7049 (dfs_accumulate_vtbl_inits)  121140: 0.0%  0: 
0.0% 540720: 0.6%  0: 
0.0%  18385
ggc-common.c:193 (ggc_calloc)383944: 0.2%  30792: 
0.1% 280544: 0.3%  
13732: 0.1%   1953
cp/lex.c:693 (retrofit_lang_decl) 54180: 0.0%  17640: 
0.0% 683496: 0.7%  0: 
0.0%  26793
tree-inline.c:632 (copy_body_r)  746080: 0.3%  0: 
0.0%  0: 0.0%  0: 0.0%  
23315
tree.c:4813 (build_index_type)   702624: 0.3%  0: 
0.0%  48576: 0.1%  0: 0.0%   
7825
tree.c:4910 (build_array_type)   696480: 0.3%  0: 
0.0%  55488: 0.1%  0: 0.0%   
7833
cp/typeck.c:3701 (build_address) 307424: 0.1%  0: 
0.0% 498912: 0.5%  0: 
0.0%  25198
gimplify.c:476 (internal_get_tmp_var)   1062792: 0.4%  0: 
0.0%  0: 0.0%  0: 0.0%  
29522
cp/class.c:7381 (build_vbase_offset_vtbl_entries1064712: 0.4%  0: 
0.0%  0: 0.0%  0: 
0.0%  44363
tree.c:4963 (build_function_type)   1093632: 0.4%  0: 
0.0% 121536: 0.1%  0: 
0.0%  12658
cp/lex.c:748 (copy_decl)  13104: 0.0%  0: 
0.0%1242932: 1.3%  62528: 0.2%   
9619
cp/class.c:7571 (add_vcall_offset)0: 0.0%1461232: 
4.1%1612536: 1.7% 830176: 
3.1%   4408
stringpool.c:77 (alloc_node)  0: 0.0%  0: 
0.0%1769144: 1.8%  0: 0.0%  
34022
tree.c:5023 (build_method_type_directly) 827520: 0.3%  0: 
0.0%1007520: 1.1%  0: 
0.0%  19115
cp/decl2.c:142 (cp_build_parm_decl)  114048: 0.0%  0: 
0.0%1881088: 2.0%  0: 
0.0%  22672
cp/typeck.c:3713 (build_nop) 854016: 0.3%  0: 
0.0%1187744: 1.2%  0: 
0.0%  63805
tree-iterator.c:47 (alloc_stmt_list)2320176: 0.9%  0: 
0.0%  38952: 0.0%  0: 0.0%  
98297
tree-iterator.c:165 (tsi_link_after)2895444: 1.2%  0: 
0.0%  59172: 0.1%  0: 0.0% 
246218
cp/lex.c:668 (build_lang_decl)   171560: 0.1%  71888: 
0.2%2905044: 3.0% 
102068: 0.4%  26599
gimplify.c:337 (create_tmp_var_raw) 3679584: 1.5%  0: 
0.0%   1152: 0.0%  0: 
0.0%  38341
function.c:3782 (allocate_struct_function)  2851200: 1.1%  0: 
0.0%1062720: 1.1%
1130688: 4.3%   5436
integrate.c:115 (copy_decl_for_inlining)7672180: 3.1%  0: 
0.0%   1152: 0.0%  0: 
0.0%  79887
tree-inline.c:2380 (copy_tree_r)   11958124: 4.8%  0: 
0.0%  0: 0.0%  46920: 0.2% 
332081
tree.c:611 (copy_list)   590920: 0.2%  0: 
0.0%   13154456:13.8%  0: 0.0% 
545484
cp/class.c:7582 (add_vcall_offset) 14411760: 5.8%1305304: 
3.6%  0: 0.0%
4582600:17.4%  19954
cp/class.c:7233 (build_vtbl_initializer)4921824: 2.0%  0: 
0.0%   16785472:17.6%  0: 
0.0% 678353
cp/class.c:7608 (add_vcall_offset) 36323976:14.5%  0: 
0.0%  0: 0.0%  0: 0.0%
1513499
cp/class.c:7257 (build_vtbl_initializer)   36835968:14.7%  0: 
0.0%  0: 0

[Bug gcov/profile/23052] return of class object sometimes reported as uncovered code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:43 ---
This is a dup of bug 12076.  The bug is in the C++ front-end removing the 
return statement as result 
is replaced with the returned structure.

*** This bug has been marked as a duplicate of 12076 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23052

[Bug c++/12076] gcov misreports coverage of return statement [NVR]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:43 ---
*** Bug 23052 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jbuck at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12076

[Bug middle-end/20826] 4.0 regression: excessive compiler resource usage

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:52 ---
This is much improved on the mainline, I don't know what caused it though.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826

[Bug middle-end/20826] 4.0 regression: excessive compiler resource usage

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||22392


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826

[Bug rtl-optimization/22392] Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
01:53 ---
I think this is the same bug as PR 20826.

-- 
   What|Removed |Added

OtherBugsDependingO||20826
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22392

[Bug middle-end/12392] very long optimized compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
02:01 ---
At -O0:
function.c:3782 (allocate_struct_function)   825840: 0.6%  0: 
0.0%1059120: 7.2% 
544544: 3.8%   2618
cfg.c:211 (connect_dest)1989960: 1.5% 146112: 
0.3%  0: 0.0%  74328: 
0.5%  77610
emit-rtl.c:3303 (make_jump_insn_raw)2024820: 1.5%  0: 
0.0%  0: 0.0% 269976: 
1.9%  33747
cfgrtl.c:3079 (init_rtl_bb_info)2040984: 1.5%  0: 
0.0%  0: 0.0% 226776: 1.6%  
56694
genrtl.c:379 (gen_rtx_fmt_e0)   2001048: 1.5%  0: 
0.0%  43056: 0.3%  0: 0.0% 
170342
emit-rtl.c:3324 (make_call_insn_raw)2076060: 1.6%  0: 
0.0%  0: 0.0% 276808: 
1.9%  34601
cgraph.c:289 (cgraph_create_edge)   2249408: 1.7%  0: 
0.0%  0: 0.0% 160672: 
1.1%  40168
tree-iterator.c:165 (tsi_link_after)2503236: 1.9%  0: 
0.0%  49488: 0.3%  0: 0.0% 
212727
ggc-common.c:193 (ggc_calloc)   1755288: 1.3% 641100: 
1.4% 823352: 5.6% 
148744: 1.0%   4507
varray.c:141 (varray_init)  3024252: 2.3%  17624: 
0.0%400: 0.0% 521460: 
3.6%   2724
gimplify.c:337 (create_tmp_var_raw) 3187680: 2.4%  0: 
0.0%  65952: 0.5%  0: 
0.0%  33892
genrtl.c:349 (gen_rtx_fmt_i00)  3437856: 2.6%  0: 
0.0%  32336: 0.2%  0: 0.0% 
216887
varray.c:174 (varray_grow)  4153452: 3.1%4096304: 
9.0% 270608: 1.8%
1766316:12.2%244
gimplify.c:293 (create_artificial_label)4686600: 3.5%  0: 
0.0%  0: 0.0%  0: 0.0%  
46866
tree-inline.c:2380 (copy_tree_r)5885104: 4.4%  0: 
0.0%140: 0.0%  33832: 
0.2% 177906
rtl.c:249 (copy_rtx)5910744: 4.5%  0: 
0.0%  0: 0.0%  0: 0.0% 
533747
cfg.c:135 (alloc_block) 8026200: 6.1%  0: 
0.0%  0: 0.0%1234800: 8.5%  
77175
emit-rtl.c:3271 (make_insn_raw) 8657000: 6.5%  0: 
0.0%  0: 0.0%  0: 0.0% 
216425
genrtl.c:17 (gen_rtx_fmt_ee)9717744: 7.3%  0: 
0.0%  16596: 0.1%  0: 0.0% 
811195



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392

[Bug libstdc++/23053] New: Const-correctness issue in TR1 hashtable

[evilalias at hotmail dot com]

I get errors when I try to compile the following bit of code:

#include 

int main()
{
std::tr1::unordered_set s;

const std::tr1::unordered_set &s_ref = s;

s_ref.find(27); // Problem is here.

return 0;
}

It appears that hashtable::find_node should be marked as a const member 
function and isn't. Putting const in (see below) seems to let the thing work, 
though I haven't tested it rigorously.

debian-800:/usr/include/c++/4.0/tr1# diff hashtable-orig hashtable-fixed
863c863
<   node* find_node (node* p, const key_type& k, typename 
hashtable::hash_code_t c);
---
>   node* find_node (node* p, const key_type& k, typename hashtable::hash_code_t
c) const;
1219c1219
< ::find_node (node* p, const key_type& k, typename hashtable::hash_code_t code)
---
> ::find_node (node* p, const key_type& k, typename hashtable::hash_code_t code)
const

Here's the full text of the error I get:

[EMAIL PROTECTED]:~/c$ g++-4.0 -v -save-temps -fmessage-length=80 temp.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)
 /usr/lib/gcc/i486-linux-gnu/4.0.1/cc1plus -E -quiet -v -D_GNU_SOURCE temp.cpp
-mtune=i486 -fmessage-length=80 -fpch-preprocess -o temp.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i486-linux-gnu/4.0.1/../../../../include/c++/4.0.1
 /usr/lib/gcc/i486-linux-gnu/4.0.1/../../../../include/c++/4.0.1/i486-linux-gnu
 /usr/lib/gcc/i486-linux-gnu/4.0.1/../../../../include/c++/4.0.1/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.0.1/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.0.1/cc1plus -fpreprocessed temp.ii -quiet
-dumpbase temp.cpp -mtune=i486 -auxbase temp -version -fmessage-length=80 -o 
temp.s
GNU C++ version 4.0.1 (Debian 4.0.1-2) (i486-linux-gnu)
compiled by GNU C version 4.0.1 (Debian 4.0.1-2).
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32148
/usr/lib/gcc/i486-linux-gnu/4.0.1/../../../../include/c++/4.0.1/tr1/hashtable: 
In
   member function 'typename std::tr1::hashtable::const_iterator std::tr1::hashtable::find(const Key&) const
   [with Key = int, Value = int, Allocator = std::allocator, ExtractKey =
   Internal::identity, Equal = std::equal_to, H1 =
   std::tr1::hash, H2 = Internal::mod_range_hashing, H =
   Internal::default_ranged_hash, RehashPolicy = Internal::prime_rehash_policy,
   bool cache_hash_code = false, bool mutable_iterators = false, bool
   unique_keys = true]':
temp.cpp:9:   instantiated from here
/usr/lib/gcc/i486-linux-gnu/4.0.1/../../../../include/c++/4.0.1/tr1/hashtable:1135:
error: passing
   'const std::tr1::hashtable,
   Internal::identity, std::equal_to, std::tr1::hash,
   Internal::mod_range_hashing, Internal::default_ranged_hash,
   Internal::prime_rehash_policy, false, false, true>' as 'this' argument of '
   typename std::tr1::hashtable::node*
   std::tr1::hashtable::find_node(Internal::hash_node*, const
   Key&, typename std::tr1::hashtable::hash_code_t) [with Key = int, Value = int, Allocator =
   std::allocator, ExtractKey = Internal::identity, Equal =
   std::equal_to, H1 = std::tr1::hash, H2 =
   Internal::mod_range_hashing, H = Internal::default_ranged_hash, RehashPolicy
   = Internal::prime_rehash_policy, bool cache_hash_code = false, bool
   mutable_iterators = false, bool unique_keys = true]' discards qualifiers

-- 
   Summary: Const-correctness issue in TR1 hashtable
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: evilalias at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053

[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable

[evilalias at hotmail dot com]

--- Additional Comments From evilalias at hotmail dot com  2005-07-25 02:08 
---
Created an attachment (id=9356)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9356&action=view)
Preprocessed test case (112 KB)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053

[Bug c/23054] New: Segmentation fault when large static array is declared

[relf at os2 dot ru]

The following program causes Segmentation fault being compiled with
gcc (GCC) 4.0.1 (Debian 4.0.1-2)

#include 
int main() {
char A[ 1UL << 24 ];
A[0] = 0;
puts("OK");
return 0;
}

$ gcc test.c
$ ./a.out
Segmentation fault

If array of the same size (16M) is dinamically allocated (e.g., via malloc())
everything works as expected.

debian-amd64 with 4G physical memory here.

-- 
   Summary: Segmentation fault when large static array is declared
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: relf at os2 dot ru
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23054

[Bug c/23054] Segmentation fault when large static array is declared

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
02:49 ---
This is not a bug.  You are overflowing the stack.  You either can use malloc
or raise the stack limit.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23054

[Bug middle-end/12392] very long optimized compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
02:53 ---
at -O1:
tree-inline.c:1114 (setup_one_parameter)4402512: 0.3%  0: 
0.0%  0: 0.0%  0: 
0.0% 122292
gimple-low.c:529 (record_vars)  4410336: 0.3%  0: 
0.0%  0: 0.0%  0: 0.0% 
183764
cfgrtl.c:3079 (init_rtl_bb_info)5156316: 0.3%  0: 
0.0%  0: 0.0% 572924: 0.3% 
143231
tree-dfa.c:605 (referenced_var_insert)  5517296: 0.4%  0: 
0.0%  0: 0.0%  0: 0.0% 
689662
tree-ssa-alias.c:2027 (get_ptr_info)5607720: 0.4%  0: 
0.0%  0: 0.0%  0: 0.0% 
467310
genrtl.c:349 (gen_rtx_fmt_i00)  6395728: 0.4%  0: 
0.0% 243072: 0.6%  0: 
0.0% 414925
tree-ssa-dom.c:2713 (record_equivalences_from_st6769728: 0.4%  0: 
0.0%  0: 0.0%  
0: 0.0% 188048
tree-vn.c:69 (make_value_handle)7638648: 0.5%  0: 
0.0%  0: 0.0%  0: 0.0% 
318277
gimplify.c:337 (create_tmp_var_raw) 7022976: 0.5%  0: 
0.0% 660096: 1.7%  0: 
0.0%  80032
emit-rtl.c:3303 (make_jump_insn_raw)7961520: 0.5%  0: 
0.0%  0: 0.0%1061536: 
0.5% 132692
tree-inline.c:2026 (expand_call_inline) 6720660: 0.4%  0: 
0.0%1598820: 4.0%
1109264: 0.5% 138658
bitmap.c:256 (bitmap_gc_alloc)  8356064: 0.5%  0: 
0.0%  0: 0.0%  0: 0.0% 
522254
tree-ssa-dom.c:1435 (build_and_record_new_cond) 8475300: 0.6%  0: 
0.0%  0: 0.0%  
0: 0.0% 235425
tree-phinodes.c:156 (allocate_phi_node) 8808280: 0.6%  0: 
0.0%  0: 0.0%  35928: 
0.0%  53093
rtl.c:249 (copy_rtx)9387708: 0.6%  0: 
0.0%  0: 0.0%  0: 0.0% 
815316
varray.c:141 (varray_init)  9915332: 0.6% 481852: 
0.2% 370040: 0.9%1646296: 
0.7% 116380
tree-iterator.c:47 (alloc_stmt_list)   11277432: 0.7%  0: 
0.0%  33024: 0.1%  0: 0.0% 
471269
tree-inline.c:2115 (expand_call_inline)11455320: 0.7%  0: 
0.0%  0: 0.0%  0: 0.0% 
477305
bitmap.c:137 (bitmap_element_allocate) 12138192: 0.8%  0: 
0.0%  0: 0.0%
1348688: 0.6% 337172
integrate.c:107 (copy_decl_for_inlining)   10045152: 0.7%  0: 
0.0%2254752: 5.7%  0: 
0.0% 128124
ggc-common.c:193 (ggc_calloc)  11854012: 0.8%8921200: 
4.4% 951568: 2.4%
1855448: 0.8%   1989
cfg.c:211 (connect_dest)   13400200: 0.9% 319208: 
0.2%  0: 0.0% 122512: 
0.1% 551052
cfg.c:202 (connect_src)13414968: 0.9%  0: 
0.0%  0: 0.0%  0: 0.0% 
558957
gimplify.c:293 (create_artificial_label)   15505400: 1.0%  0: 
0.0%  0: 0.0%  0: 0.0% 
155054
emit-rtl.c:3271 (make_insn_raw)16349680: 1.1%  0: 
0.0%  0: 0.0%  0: 0.0% 
408742
cgraph.c:168 (cgraph_create_node)  16722960: 1.1%  0: 
0.0%  18480: 0.0%
1116096: 0.5% 139512
tree-dfa.c:198 (create_tree_ann)   19402916: 1.3%  0: 
0.0%   3432: 0.0%  0: 0.0% 
373199
genrtl.c:17 (gen_rtx_fmt_ee)   19784544: 1.3%  0: 
0.0%  28836: 0.1%  0: 0.0%
1651115
cgraph.c:289 (cgraph_create_edge)  21175504: 1.4%  0: 
0.0%  0: 0.0%1512536: 
0.7% 378134
tree-inline.c:421 (remap_block)18648780: 1.2%  0: 
0.0%4599960:11.6%
3099832: 1.4% 387479
varray.c:174 (varray_grow) 30049364: 2.0%   
29294196:14.5% 323700: 0.8%   
13783580: 6.2%   3892
tree-iterator.c:165 (tsi_link_after)   31498620: 2.0%  0: 
0.0%  49488: 0.1%  0: 0.0%
2629009
convert.c:457 (convert_to_integer) 32215072: 2.1%  0: 
0.0% 32: 0.0%  0: 0.0%
1006722
tree-ssanames.c:147 (make_ssa_name)3404: 2.2%  0: 
0.0%5705492:14.4%  
0: 0.0% 750748
tree-dfa.c:175 (create_stmt_ann)   56146220: 3.7%   17495556: 
8.7% 52: 0.0%  0: 
0.0%1416189
cfg.c:135 (alloc_block)58116344: 3.8%  0: 
0.0%  0: 0.0%8940976: 4.0% 
558811
integrate.c:115 (copy_decl_for_inlining)   52512932: 3.4%  0: 
0.0%6518784:16.5%  0: 
0.0% 609815
tree-inline.c:2380 (copy_tree_r)   73114672: 4.8%  0: 
0.0%  

[Bug rtl-optimization/13931] [3.4/4.0/4.1 Regression] combiner much slower on big basic blocks

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
02:59 ---
I think this has been fixed on the mainline:
600   .7s
12001.899s
18003.7s
24005.945s

This is all with checking still enabled.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931

[Bug tree-optimization/15678] [4.0/4.1 Regression] CSiBE i686 compilation time increased by 8% at -O2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
03:09 ---
Even at -O0, the small testcase hs increased in compile time.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15678

[Bug tree-optimization/15678] [4.0/4.1 Regression] CSiBE i686 compilation time increased by 8% at -O2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-25 
03:18 ---
Huh, at -O0:
tree-ssanames.c:82 (init_ssanames)0: 0.0%
9961472:46.6%  0: 0.0%1572864: 
4.5%  32768

This seems high:
function.c:3782 (allocate_struct_function) 23594400: 8.2%  0: 
0.0%  0: 0.0%6816160:
19.5%  32770

too

-- 
   What|Removed |Added

   Keywords||memory-hog


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15678