[Bug libstdc++/21295] Configuring g++ library for various locales ?

[jpr at essi dot fr]

--- Additional Comments From jpr at essi dot fr  2005-05-01 06:10 ---
Subject: Re:  Configuring g++ library for various locales
 ?

pcarlini at suse dot de wrote:

>--- Additional Comments From pcarlini at suse dot de  2005-04-30 21:24 
>---
>For that kind of GNU x86-linux platform we have, literally, thousands of
>succesful reports, everything is supposed to work well out-of-the-box. In 
>particular, the GNU locale model, supporting named locales is selected 
>automatically, by default.
>
>I can try to help you a bit figuring out what's wrong with your specific
>setup but this isn't really our job, here, sorry.
>  
>
I understand this, but I also understant that we are all committed to 
improve the quality of the free tools we use :-)

>Anyway, are you building GCC? You should do that if you want to double check
>that the right (GNU) locale model is actually used. You can check whether
>this is the case by ooking at c++locale.h header in your install directory, 
>under /include/c++/4.0.0/i686-pc-linux-gnu/bits. Close to the beginning of
>the file you should find something like:
>
>#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
>namespace __gnu_cxx
>{
>  extern "C" __typeof(uselocale) __uselocale;
>}
>#endif
>
>Then, we can actually understand whether the problem begins at GCC configure
>and build time.
>
>  
>
That's the point, I do not have these lines (I attach my c++locale.h 
from my 4.0.0 by=uild, since it is short).

Jean-Paul Rigault


// Wrapper for underlying C-language localization -*- C++ -*-

// Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 2, or (at your option)
// any later version.

// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.

// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING.  If not, write to the Free
// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
// USA.

// As a special exception, you may use this file as part of a free software
// library without restriction.  Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License.  This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.

//
// ISO C++ 14882: 22.8  Standard locale categories.
//

// Written by Benjamin Kosnik <[EMAIL PROTECTED]>

#ifndef _C_LOCALE_H
#define _C_LOCALE_H 1

#pragma GCC system_header

#include 
#include// get std::strlen
#include // get std::snprintf or std::sprintf

#define _GLIBCXX_NUM_CATEGORIES 0

namespace std
{
  typedef int*  __c_locale;

  // Convert numeric value of type _Tv to string and return length of
  // string.  If snprintf is available use it, otherwise fall back to
  // the unsafe sprintf which, in general, can be dangerous and should
  // be avoided.
  template
int
__convert_from_v(char* __out, 
 const int __size __attribute__((__unused__)),
 const char* __fmt,
 _Tv __v, const __c_locale&, int __prec)
{
  char* __old = std::setlocale(LC_NUMERIC, NULL);
  char* __sav = NULL;
  if (std::strcmp(__old, "C"))
{
  __sav = new char[std::strlen(__old) + 1];
  std::strcpy(__sav, __old);
  std::setlocale(LC_NUMERIC, "C");
}

#ifdef _GLIBCXX_USE_C99
  const int __ret = std::snprintf(__out, __size, __fmt, __prec, __v);
#else
  const int __ret = std::sprintf(__out, __fmt, __prec, __v);
#endif
  
  if (__sav)
{
  std::setlocale(LC_NUMERIC, __sav);
  delete [] __sav;
}
  return __ret;
}
}

#endif


-- 


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

[Bug c++/16370] __attribute__((deprecated)) not useful on classes, and ugly function name listed for deperecation warnings on constructor

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-01 05:21 ---
Subject: Re:  __attribute__((deprecated)) not useful on classes, and ugly 
function name listed for deperecation warnings on constructor

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

| --- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:41 ---
| We now get:
| t.cc:36: warning: ‘__comp_ctor ’ is deprecated (declared at t.cc:18)
| 
| note the extra space.

The extra space is part of the name, if you ask me.

-- Gaby


-- 


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

Re: [Bug c++/16370] __attribute__((deprecated)) not useful on classes, and ugly function name listed for deperecation warnings on constructor

[Gabriel Dos Reis]

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

| --- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:41 ---
| We now get:
| t.cc:36: warning: Â__comp_ctor  is deprecated (declared at t.cc:18)
| 
| note the extra space.

The extra space is part of the name, if you ask me.

-- Gaby

[Bug target/9186] [i686] async exception from a signal handler not working as before

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
04:47 ---
Actually the problem is that strcpy is not compiled with -fexceptions, 
-fnon-call-exceptions so this is 
not a bug after all.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug target/17174] Fortran nearest broken on AIX

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-01 04:34:06
   date||


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

[Bug tree-optimization/15256] [tree-ssa] Optimize manual bitfield manipilation.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
04:16 ---
If fold optimized the following function:

unsigned int
foo (unsigned int eax)
{
  return (eax & 1) ^ 1 | (eax & 0xfffe);
}

Then the tree combiner might be able to optimize the orginal one.

-- 
   What|Removed |Added

OtherBugsDependingO|19466   |15459, 19987
  nThis||
   Last reconfirmed|2004-11-22 02:00:52 |2005-05-01 04:16:44
   date||


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[olh at suse dot de]

--- Additional Comments From olh at suse dot de  2005-05-01 04:11 ---
gcc 4.1 with --disable-checking took 3:28:00 h:mm:ss


-- 


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

[Bug c++/9728] Err in non-virtual func name in dump class file

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:59 ---
Fixed since at least 4.0.0.

-- 
   What|Removed |Added

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


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

[Bug c++/7585] Attributes for nested typedef-name ignored

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:55 ---
Fixed in 4.0.0.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords||wrong-code
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug c++/16370] __attribute__((deprecated)) not useful on classes, and ugly function name listed for deperecation warnings on constructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:41 ---
We now get:
t.cc:36: warning: ‘__comp_ctor ’ is deprecated (declared at t.cc:18)

note the extra space.

-- 
   What|Removed |Added

   Last reconfirmed|2004-11-01 00:28:00 |2005-05-01 03:41:47
   date||


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

[Bug c++/18886] misleading warning from attribute sentinel in C++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:39 ---
*** Bug 19542 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||marcus at jet dot franken
   ||dot de


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:39 ---
To Mark as a dup of bug 18886.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:39 ---
Reopening to ..

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/19377] Using declaration in "private" part causes "protected" diagnostic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:34 ---
(In reply to comment #0)
> (It actually prints the message twice, but that's PR 19375)
Actually it was not, it was a related case but we still get the message twice, 
I filed PR 21312 with a 
modifed testcase without the use of using.

-- 
   What|Removed |Added

   Last reconfirmed|2005-01-11 17:08:01 |2005-05-01 03:34:00
   date||


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

[Bug c++/21312] [3.4/4.0/4.1 Regression] Access violation diagnostic given twice

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.0.1   |3.4.4


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

[Bug c++/21312] [3.4/4.0/4.1 Regression] Access violation diagnostic given twice

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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

[Bug c++/21312] New: [3.4/4.0/4.1 Regression] Access violation diagnostic given twice

[pinskia at gcc dot gnu dot org]

Like PR 19375, the following code gives the diagnostic twice:
class A {
private:
int i;
};
class B : public A {
};
class C : public B {
public:
void f() { A::i = 0; }
};

-- 
   Summary: [3.4/4.0/4.1 Regression] Access violation diagnostic
given twice
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: diagnostic
  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


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

[Bug c++/16468] [DR460] using-declaration of namespace name

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
03:16 ---
Hmm, it looks like GCC is going to be correct and rejecting this.  The DR is 
now in ready state (I forgot 
what this means).

-- 
   What|Removed |Added

   Last reconfirmed|2005-01-11 02:31:10 |2005-05-01 03:16:13
   date||


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

[Bug c++/19407] vector keyword in typedef inside template struct ignored

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
02:53 ---
Now we get an error:
t.cc:3: sorry, unimplemented: applying attributes to template parameters is not 
implemented

So this is definitely PR 17743

-- 


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

[Bug c++/19249] abstract classes should not access virtually inherited class constructor

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||3.3.4 3.4.0 3.4.1 3.4.2
   ||3.4.3 4.0.0 2.95.3


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
02:29 ---
Removing 3.3.3 as the code which caused this is there just not active as 
-fabi-version=2 is needed to 
reproduce it.

-- 
   What|Removed |Added

  Known to work|3.3.3   |3.2.3


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

[Bug c++/18462] [3.4 Regression] Segfault on declaration of large array member

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
02:28 ---
Oh, this is reproducable in 3.3.3 with -fabi-version=2.

-- 


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

[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
02:10 ---
Both this and PR 18462 are caused by:
2002-09-30  Mark Mitchell  <[EMAIL PROTECTED]>

* class.c (walk_subobject_offsets): Correct the calculation of
offsets for virtual bases.  Correct the counting of array 
elements.


-- 
   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org
Summary|[4.0/4.1 Regression] Very   |[3.4/4.0/4.1 Regression]
   |high compile time   |Very high compile time
   Target Milestone|4.0.1   |3.4.4


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

[Bug c++/18462] [3.4 Regression] Segfault on declaration of large array member

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
02:10 ---
Both this and PR 21308 are caused by:
2002-09-30  Mark Mitchell  <[EMAIL PROTECTED]>

* class.c (walk_subobject_offsets): Correct the calculation of
offsets for virtual bases.  Correct the counting of array 
elements.


-- 


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

[Bug java/20309] gcjh needs a -force option

[fitzsim at redhat dot com]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fitzsim at redhat dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-01 
01:13 ---
Subject: Bug 19542

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-01 01:13:09

Modified files:
gcc: c-common.h c-opts.c c.opt c-common.c ChangeLog 
gcc/doc: invoke.texi 
gcc/cp : cp-tree.h lex.c ChangeLog 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/warn: sentinel.C 

Log message:
ChangeLog:
PR c++/19542
* c-common.c (c_common_nodes_and_builtins): Create global null_node.
(warn_strict_null_sentinel): Define.
(check_function_sentinel): Check for null_node as valid sentinel too.
* c-common.h (c_tree_index): Added CTI_NULL.
(null_node) Define global_tree[CTI_NULL].
(warn_strict_null_sentinel): Declare.
* c-opts.c: (c_common_handle_option): Handle -Wstrict-null-sentinel.
* c.opt: (Wstrict-null-sentinel): New C++ option.
* doc/invoke.texi (C++ Options): Document -Wstrict-null-sentinel.

cp/ChangeLog:
PR c++/19542
* cp-tree.h (cp_tree_index): Remove CPTI_NULL, to be defined in C
common frontend.
(null_node): Remove.
* lex.c (cxx_init): Move null_node initialisation to C common frontend.

testsuite/ChangeLog:
PR c++/19542
* g++.dg/warn/sentinel.C: New testcase for __null sentinels added.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.277.2.1&r2=1.277.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.136.2.2&r2=1.136.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c.opt.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.8.3&r2=1.34.8.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.606.2.2&r2=1.606.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.207&r2=2.7592.2.208
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.583.2.15&r2=1.583.2.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106.2.3&r2=1.1106.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/lex.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.353&r2=1.353.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.36&r2=1.4648.2.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/sentinel.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.151&r2=1.5084.2.152



-- 


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

[Bug tree-optimization/21266] [4.1 Regression] verify_ssa failed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
01:06 ---
*** Bug 21311 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||tprince at computer dot org


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

[Bug tree-optimization/21311] ice on valid code tree-vectorize (max of float array)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-01 
01:06 ---
Fixed yesterday.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |tree-optimization
 Resolution||DUPLICATE


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

[Bug java/15525] suggestion to enable cast elimination

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-01 
00:57 ---
There are a couple more cases where explicit casts can be eliminated.

Code like this will introduce an unneeded cast:

   Object o = "something";
   String s = (String) o;

Of course this is the simplest possible case; I don't know whether
this occurs in real code or not.


Another case is rearranging an array:

   Object[] array = something();
   array[0] = array[1];

This will generate a call to check whether the array can hold the
object, due to the special role arrays play in the type system;
for example this is valid but throws an exception at runtime:

   String[] sarray = ...;
   Object[] oarray = sarray;
   oarray[0] = new Integer(5);

... because Integer can't be cast to String.
In the first array example, we know that the check can be
eliminated because the rhs of the assignment comes from the
same array.

Currently we emit calls to _Jv_CheckArrayStore for this situation.
While we could inline it (making the type check explicit and allowing
elimination in the style of the other parts of this PR), size of the generated
code might be a concern.

Sometimes the precise type of an array is known, for instance if it
is the result of a 'new'.  In this case it would be nice to be able
to eliminate even more checks.


-- 


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

[Bug c/21311] ice on valid code tree-vectorize (max of float array)

[tprince at computer dot org]

--- Additional Comments From tprince at computer dot org  2005-05-01 00:34 
---
Created an attachment (id=8779)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8779&action=view)
pre-processed C code exhibiting ice in -ftree-vectorize

This is the netlib Levine-Callahan-Dongarra vector function s314, C
translation.

-- 


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

[Bug c/21311] New: ice on valid code tree-vectorize (max of float array)

[tprince at computer dot org]

gcc -O -march=pentium4  -ftree-vectorize -c -std=c99 -v loopsv.c
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --enable-languages=c c++ f95 objc treelang
--enable-threads=posix --enable-sjlj-exceptions --disable-libmudflap
--disable-shared
Thread model: posix
gcc version 4.1.0 20050424 (experimental)
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
s314.c:2: warning: return type defaults to 'int'
s314.c: In function 's314_':
s314.c:2: error: Definition in block 4 follows the use
for SSA_NAME: i___23 in statement:
x_2 = i__2_15 >= i___23 ? x_22 : x_25;
s314.c:2: internal compiler error: verify_ssa failed.

-- 
   Summary: ice on valid code tree-vectorize (max of float array)
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tprince at computer dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |4.0.1


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:47 ---
Depending on the 3.4 bug.

-- 
   What|Removed |Added

  BugsThisDependsOn||18462
  Known to fail||4.0.0 4.1.0
  Known to work||3.3.3
   Target Milestone|4.0.1   |3.4.4


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

[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and "inline function used but never defined"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:42 ---
Mark you added the code to lazy create the deconstructors, would you look into 
this problem?

-- 
   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug target/21309] internal compiler error: in expand_mult_const, at expmed.c:2884

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug middle-end/21124] [4.1 regression] bogus "may be used uninitialized" warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:38 ---
*** Bug 21310 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||wanderer at rsu dot ru


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

[Bug c++/21310] warning: '' may be used uninitialized in this function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:38 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:37 ---
(In reply to comment #4)
> Yup, compute_flow_insensitive_aliasing is taking forever on these files (I
> stopped it at >2 hours for the TV_ALIAS_ANALYSIS timevar)
> Probably another reason we shouldn't compute aliasing 5 times :)

But two hours/5 is still high.

-- 


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:36 ---
Note this is a reduced testcase from ssb:
struct T { struct {} t [1<<21]; };

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||compile-time-hog
   Last reconfirmed|-00-00 00:00:00 |2005-04-30 23:36:34
   date||
   Target Milestone|--- |4.0.1


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-30 
23:25 ---
If we used integers instead of computing this all using size_binop, this
testcase would take no time at all

-- 


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

[Bug target/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
23:20 ---
This is more likely a target bug.

-- 
   What|Removed |Added

  Component|rtl-optimization|target
   Keywords||ice-on-valid-code


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-30 
23:07 ---
All the time is in walk_subobject_offsets.
...

#10 0x080e8dc9 in walk_subobject_offsets (type=0x400d08dc, f=0x80e8188
, offset=0x400261b0, offsets=0x8877418,
max_offset=0x0, vbases_p=1) at class.c:3258
#11 0x080e9655 in record_subobject_offsets (type=0x400d08dc, offset=0x400261b0,
offsets=0x8877418, vbases_p=1) at class.c:3320
#12 0x080f0e88 in layout_class_type (t=0x400d0af8, virtuals_p=0xbfffec3c) at
class.c:4674
#13 0x080f287e in finish_struct_1 (t=0x400d0af8) at class.c:4942
#14 0x080f4002 in finish_struct (t=0x400d0af8, attributes=0x0) at class.c:5137
#15 0x08128075 in cp_parser_class_specifier (parser=0x400c0750) at 
parser.c:12494


-- 


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-30 
23:04 ---
Yup, compute_flow_insensitive_aliasing is taking forever on these files (I
stopped it at >2 hours for the TV_ALIAS_ANALYSIS timevar)
Probably another reason we shouldn't compute aliasing 5 times :)

-- 


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

[Bug libstdc++/21286] [4.0/4.1 Regression] filebuf::xsgetn vs pipes

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-30 22:57 
---
Should now be fixed for 4.1.0 and 4.0.1. Ralf, if you get a chance to test a
4.0.1 snapshot...

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/21286] [4.0/4.1 Regression] filebuf::xsgetn vs pipes

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-30 
22:55 ---
Subject: Bug 21286

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-30 22:55:34

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/bits: fstream.tcc 

Log message:
2005-04-30  Paolo Carlini  <[EMAIL PROTECTED]>
Nathan Myers  <[EMAIL PROTECTED]>

PR libstdc++/21286
* include/bits/fstream.tcc (basic_filebuf<>::xsgetn):
Loop on short reads; remove the work-around for
libstdc++/20806, not needed anymore.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2917.2.35&r2=1.2917.2.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/fstream.tcc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.128.10.1&r2=1.128.10.2



-- 


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

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-04-30 22:16 ---
Subject: Re:  Configuring g++ library for various locales ?

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

| >  I understand that bugzilla is not a hotline, but we would not need
| > to be harsh
| 
| Gaby, nobody is harsh here. I'm only admitting publically that I'm not sure to
| be able to follow personally all the details of this PR, for all the reasons 
that
| you clearly explained. You should probably do the same more frequently ;)

so, I should not follow the PRs more frequently?
that is an interesting suggestion :->

-- Gaby


-- 


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

[Bug c++/21310] warning: '' may be used uninitialized in this function

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2005-04-30 22:16 
---
Created an attachment (id=8778)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8778&action=view)
.ii file


-- 


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

[Bug c++/21310] New: warning: '' may be used uninitialized in this function

[wanderer at rsu dot ru]

Current mainline GCC generate strage warnings with -O -Wuninitialized options 
if compile testcase:

--8X-
#include

struct W {
  static int g(int v) { return std::min(v,0); }
};

struct R {
  R();
  R(int v);
  int m;
};

int main() {
  std::map e;
  e[0] = R(W::g(0));
}
--X8--

Output:
test.cc: In function 'int main()':
test.cc:4: warning: '' may be used uninitialized in this function
test.cc:15: warning: 'v' may be used uninitialized in this function

GCC 4.0.0 compile with same options without warnings.

Vladimir

-- 
   Summary: warning: '' may be used uninitialized in this
function
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-unknown-freebsd5.3
  GCC host triplet: i386-unknown-freebsd5.3
GCC target triplet: i386-unknown-freebsd5.3


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

[Bug other/19509] Building 3.4.3 on Solaris 9 fixinc.sh Fails

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-04-30 
22:12 ---
No feedback in 3 months.


-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug target/21309] internal compiler error: in expand_mult_const, at expmed.c:2884

[matt at 3am-software dot com]

--- Additional Comments From matt at 3am-software dot com  2005-04-30 22:11 
---
Created an attachment (id=8777)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8777&action=view)
C file causing the ICE


-- 


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

[Bug rtl-optimization/15248] [4.0 Regression] Reload may generate stores to read-only memory

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-04-30 
22:10 ---
The same fix was applied to mainline.  Jeff, please consider backporting your
patch to 4.0 branch so that we be definitely done with this nasty problem.


-- 
   What|Removed |Added

Summary|[4.0/4.1 Regression] Reload |[4.0 Regression] Reload may
   |may generate stores to read-|generate stores to read-only
   |only memory |memory


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

[Bug target/21309] internal compiler error: in expand_mult_const, at expmed.c:2884

[matt at 3am-software dot com]

--- Additional Comments From matt at 3am-software dot com  2005-04-30 22:04 
---
Created an attachment (id=8776)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8776&action=view)
source file exhibiting problem


-- 


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

[Bug target/21309] New: internal compiler error: in expand_mult_const, at expmed.c:2884

[matt at 3am-software dot com]

Using built-in specs.
Target: vax--netbsdelf
Configured with: /u1/toolchain/gcc/configure --target=vax--netbsdelf --build=x86
_64--netbsd --host=x86_64--netbsd --disable-shared --disable-threads --prefix=/u
sr/gcc
Thread model: single
gcc version 4.1.0 20050422 (experimental)
 /usr/gcc/libexec/gcc/vax--netbsdelf/4.1.0/cc1 -E -quiet -nostdinc -v -I. -isyst
em /u1/vax/root/usr/include /usr/src/games/hack/hack.bones.c -Wall -Wstrict-prot
otypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -
Wno-uninitialized -O2 -fpch-preprocess -o hack.bones.i
#include "..." search starts here:
#include <...> search starts here:
 .
 /u1/vax/root/usr/include
End of search list.
# cc1 0.02 0.01
 /usr/gcc/libexec/gcc/vax--netbsdelf/4.1.0/cc1 -fpreprocessed hack.bones.i -quie
t -dumpbase hack.bones.c -auxbase hack.bones -O2 -Wall -Wstrict-prototypes -Wmis
sing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wno-uninitia
lized -version -o hack.bones.s
GNU C version 4.1.0 20050422 (experimental) (vax--netbsdelf)
compiled by GNU C version 3.3.3 (NetBSD nb3 20040520).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/usr/src/games/hack/hack.bones.c: In function 'savebones':
/usr/src/games/hack/hack.bones.c:89: internal compiler error: in expand_mult_con
st, at expmed.c:2884
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
# cc1 0.05 0.01


Breakpoint 1, fancy_abort (file=0x937520 "/u1/toolchain/gcc/gcc/expmed.c", 
line=2884, function=0x9375f0 "expand_mult_const")
at /u1/toolchain/gcc/gcc/diagnostic.c:571
571   internal_error ("in %s, at %s:%d", function, trim_filename (file), 
line);
(gdb) where
#0  fancy_abort (file=0x937520 "/u1/toolchain/gcc/gcc/expmed.c", line=2884, 
function=0x9375f0 "expand_mult_const")
at /u1/toolchain/gcc/gcc/diagnostic.c:571
#1  0x0065f41b in expand_mult_const (mode=SImode, op0=0x2011e30c0, 
val=26215, target=0x0, alg=0x7f7fcb50, variant=basic_variant)
at /u1/toolchain/gcc/gcc/expmed.c:2884
#2  0x00660b8a in expand_mult_highpart (mode=HImode, op0=0x2011d17e0, 
op1=0x201183bd0, target=0x0, unsignedp=0, max_cost=2147483619)
at /u1/toolchain/gcc/gcc/expmed.c:3484
#3  0x00662038 in expand_divmod (rem_flag=0, code=TRUNC_DIV_EXPR, 
mode=HImode, op0=0x2011d17e0, op1=0x200eed4a0, target=0x0, unsignedp=0)
at /u1/toolchain/gcc/gcc/expmed.c:4143
#4  0x00685866 in expand_expr_real_1 (exp=0x2010aecd0, target=0x0, 
tmode=QImode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /u1/toolchain/gcc/gcc/expr.c:7799
#5  0x006780ef in expand_expr_real (exp=0x2010aecd0, target=0x0, 
tmode=QImode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /u1/toolchain/gcc/gcc/expr.c:6416
#6  0x0068d4e3 in expand_expr (exp=0x2010aecd0, target=0x0, 
mode=QImode, modifier=EXPAND_NORMAL) at expr.h:487
#7  0x0067ebb7 in expand_expr_real_1 (exp=0x2010add00, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /u1/toolchain/gcc/gcc/expr.c:7408
---Type  to continue, or q  to quit---
#8  0x006780ef in expand_expr_real (exp=0x2010add00, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /u1/toolchain/gcc/gcc/expr.c:6416
#9  0x0068d4e3 in expand_expr (exp=0x2010add00, target=0x0, 
mode=VOIDmode, modifier=EXPAND_NORMAL) at expr.h:487
#10 0x0067770c in expand_operands (exp0=0x2010add00, exp1=0x20116e4e0, 
target=0x0, op0=0x7f7fde58, op1=0x7f7fde50, modifier=EXPAND_NORMAL)
at /u1/toolchain/gcc/gcc/expr.c:6143
#11 0x00681d31 in expand_expr_real_1 (exp=0x2010aedc0, target=0x0, 
tmode=QImode, modifier=EXPAND_NORMAL, alt_rtl=0x7f7fdfc0)
at /u1/toolchain/gcc/gcc/expr.c:7618
#12 0x006780ef in expand_expr_real (exp=0x2010aedc0, 
target=0x2011e3080, tmode=QImode, modifier=EXPAND_NORMAL, 
alt_rtl=0x7f7fdfc0) at /u1/toolchain/gcc/gcc/expr.c:6416
#13 0x0066e599 in store_expr (exp=0x2010aedc0, target=0x2011e3080, 
call_param_p=0) at /u1/toolchain/gcc/gcc/expr.c:4170
#14 0x006731af in store_field (target=0x2011e3000, bitsize=8, 
bitpos=48, mode=QImode, exp=0x2010aedc0, type=0x20116f5b0, alias_set=0)
at /u1/toolchain/gcc/gcc/expr.c:5360
#15 0x0066d67a in expand_assignment (to=0x20116ba80, from=0x2010aedc0)
at /u1/toolchain/gcc/gcc/expr.c:3941
#16 0x00688766 in expand_expr_real_1 (exp=0x2010aee10, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
---Type  to continue, or q  to quit---
at /u1/toolchain/gcc/gcc/expr.c:8235
#17 0x006780b9 in expand_expr_real (exp=0x2010aee10, 
target=0x200eed400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /u1/toolchain/gcc/gcc/expr.c:6410
#18 0x007a54e3 in expand_expr (exp=0x2010aee10, target=0x200eed400, 
mode=VOIDmode, modifier=EXPAND_NORMAL

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-30 21:57 
---
>  I understand that bugzilla is not a hotline, but we would not need
> to be harsh

Gaby, nobody is harsh here. I'm only admitting publically that I'm not sure to
be able to follow personally all the details of this PR, for all the reasons 
that
you clearly explained. You should probably do the same more frequently ;)

-- 


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

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-04-30 21:50 ---
Subject: Re:  Configuring g++ library for various locales ?

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

| For that kind of GNU x86-linux platform we have, literally, thousands of
| succesful reports, everything is supposed to work well out-of-the-box. In 
| particular, the GNU locale model, supporting named locales is selected 
| automatically, by default.
| 
| I can try to help you a bit figuring out what's wrong with your specific
| setup but this isn't really our job, here, sorry.

Paolo -- 

  I understand that bugzilla is not a hotline, but we would not need
to be harsh when users take the time to report what appear to be
problems when using our products -- at least if we want the process to
be useful to both users and us.

  Jean-Paul has been active in C++ standardization efforts and
software business for long time now (he was among the first persons
who introduced me to the French national body and the ISO C++
committee) and I don't think he want us to solve his problem for him. 
Rather, I believe he is reporting something he thinks might be a
fundamental problem with our library.  I believe we do welcome such
reports.  I also understand that the path "the solution" might not be
easy. 

| Anyway, are you building GCC? You should do that if you want to double check
| that the right (GNU) locale model is actually used. You can check whether
| this is the case by ooking at c++locale.h header in your install directory, 
| under /include/c++/4.0.0/i686-pc-linux-gnu/bits. Close to the beginning of
| the file you should find something like:
| 
| #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
| namespace __gnu_cxx
| {
|   extern "C" __typeof(uselocale) __uselocale;
| }
| #endif
| 
| Then, we can actually understand whether the problem begins at GCC configure
| and build time.

Thanks, that suggestion is very muich appreciated.

-- Gaby


-- 


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[peturrun at internet dot is]

-- 
   What|Removed |Added

   Attachment #8775|application/octet-stream|text/plain
  mime type||


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

[Bug c/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-04-30 21:40 ---
I think DECL_NON_ADDR_CONST_P is set too late.
Regtesting a patch that fixes 21081 and this.
Danny

-- 


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

[Bug c++/21308] [4.0/4.1 Regression] Very high compile time

[peturrun at internet dot is]

--- Additional Comments From peturrun at internet dot is  2005-04-30 21:39 
---
Created an attachment (id=8775)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8775&action=view)
Preprocessed source code


-- 


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

[Bug c++/21308] New: [4.0/4.1 Regression] Very high compile time

[peturrun at internet dot is]

Compiling this program takes a very long time with GCC 4.x compared with GCC
3.3. GCC 3.4 fails to compile it, which has already been reported as PR18462.

Compile times for current mainline, GCC 4.0 and GCC 3.3 on a 500 MHz Pentium III
with 512 MB RAM:

[EMAIL PROTECTED] cgx]$ time g++-cvs -O3 -c CheckersGameX.ii

real0m41.298s
user0m39.016s
sys 0m0.958s
[EMAIL PROTECTED] cgx]$ g++-cvs -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-cvs/configure --program-suffix=-cvs
--enable-threads=posix --enable-languages=c,c++ --enable-__cxa_atexit
--prefix=/home/petur/opt/gcc-cvs --disable-checking
Thread model: posix
gcc version 4.1.0 20050430 (experimental)
[EMAIL PROTECTED] cgx]$ time g++400 -O3 -c CheckersGameX.ii

real0m43.372s
user0m39.739s
sys 0m0.966s
[EMAIL PROTECTED] cgx]$ g++400 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --program-suffix=400
--enable-version-specific-runtime-libs --enable-threads=posix
--enable-languages=c,c++,java --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0
[EMAIL PROTECTED] cgx]$ time g++335 -O3 -c CheckersGameX.ii

real0m0.115s
user0m0.051s
sys 0m0.018s
[EMAIL PROTECTED] cgx]$ g++335 -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs
Configured with: ../gcc-3.3.5/configure --program-suffix=335
--enable-threads=posix --enable-version-specific-runtime-libs
--enable-languages=c,c++
Thread model: posix
gcc version 3.3.5

-- 
   Summary: [4.0/4.1 Regression] Very high compile time
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peturrun at internet dot is
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=21308

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-30 21:30 
---
Also: if the correct (GNU) header is present, and the problem is happening 
later,
you should double check that you are installing correctly the new compilers more
generally, i.e., that, when compiling with 4.0.0 all the new libraries are 
correctly picked at application startup: please attach here the output of ldd
on an application that is giving you problems.

-- 


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

[Bug rtl-optimization/21307] internal compiler error: in change_address_1, at emit-rtl.c:1768

[matt at 3am-software dot com]

--- Additional Comments From matt at 3am-software dot com  2005-04-30 21:29 
---
Created an attachment (id=8774)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8774&action=view)
C file causing the ICE


-- 


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

[Bug rtl-optimization/21307] New: internal compiler error: in change_address_1, at emit-rtl.c:1768

[matt at 3am-software dot com]

Using built-in specs.
Target: vax--netbsdelf
Configured with: /u1/toolchain/gcc/configure --target=vax--netbsdelf
--build=x86_64--netbsd --host=x86_64--netbsd --disable-shared --disable-threads
--prefix=/usr/gcc
Thread model: single
gcc version 4.1.0 20050422 (experimental)
 /usr/gcc/libexec/gcc/vax--netbsdelf/4.1.0/cc1 -E -quiet -nostdinc -v
-I/usr/src/lib/libc/citrus -DLOCALEMOD_MAJOR=4 -DLIBC_SCCS -isystem
/u1/vax/root/usr/include /usr/src/lib/libc/citrus/modules/citrus_utf7.c -O2
-fpch-preprocess -o citrus_utf7.i
#include "..." search starts here:
#include <...> search starts here:
 /usr/src/lib/libc/citrus
 /u1/vax/root/usr/include
End of search list.
# cc1 0.02 0.00
 /usr/gcc/libexec/gcc/vax--netbsdelf/4.1.0/cc1 -fpreprocessed citrus_utf7.i
-quiet -dumpbase citrus_utf7.c -auxbase-strip citrus_utf7.o.tmp -O2 -version -o
citrus_utf7.s
GNU C version 4.1.0 20050422 (experimental) (vax--netbsdelf)
compiled by GNU C version 3.3.3 (NetBSD nb3 20040520).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/usr/src/lib/libc/citrus/modules/citrus_utf7.c: In function '_mbtoutf16':
/usr/src/lib/libc/citrus/modules/citrus_utf7.c:279: internal compiler error: in
change_address_1, at emit-rtl.c:1768
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
# cc1 0.07 0.01

-- 
   Summary: internal compiler error: in change_address_1, at emit-
rtl.c:1768
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at 3am-software dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-netbsd
  GCC host triplet: x86_64--netbsd
GCC target triplet: vax--netbsdelf


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

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-30 21:24 
---
For that kind of GNU x86-linux platform we have, literally, thousands of
succesful reports, everything is supposed to work well out-of-the-box. In 
particular, the GNU locale model, supporting named locales is selected 
automatically, by default.

I can try to help you a bit figuring out what's wrong with your specific
setup but this isn't really our job, here, sorry.

Anyway, are you building GCC? You should do that if you want to double check
that the right (GNU) locale model is actually used. You can check whether
this is the case by ooking at c++locale.h header in your install directory, 
under /include/c++/4.0.0/i686-pc-linux-gnu/bits. Close to the beginning of
the file you should find something like:

#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
namespace __gnu_cxx
{
  extern "C" __typeof(uselocale) __uselocale;
}
#endif

Then, we can actually understand whether the problem begins at GCC configure
and build time.

-- 


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

[Bug middle-end/21305] flag_delete_null_pointer_checks is target specific

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
21:19 ---
Note the flag is old, it comes from:
Thu Sep 23 13:55:21 1999  Jeffrey A Law  ([EMAIL PROTECTED])

* invoke.texi: Document -fdelete-null-pointer-checks
* toplev.c (flag_delete_null_pointer_checks): New.
(f_options): Add entry for -fdelete-null-pointer-checks.
(rest_of_compilation): Conditionalize null pointer check
elimination on flag_delete_null_pointer_checks.
(main): If -O2 or greater, enable -fdelete-null-pointer-checks


-- 


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

[Bug middle-end/21305] flag_delete_null_pointer_checks is target specific

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2005-04-30 21:18 
---
Apparently the behaviour of this code is undefined in the C/C++ language
standards, though this transformation is performed in front-end independent
code.  Perhaps its only a quality of implementation issue.


-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and "inline function used but never defined"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
21:14 ---
*** Bug 21306 has been marked as a duplicate of this bug. ***

-- 


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

[Bug c++/21306] [4.0 Regression] Another way to generate "inline function ‘A::~A()’ used but never defined" errors

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
21:14 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/21305] flag_delete_null_pointer_checks is target specific

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|tree-optimization   |middle-end


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

[Bug target/20633] [4.0 only] libgcc2.c:1623: error: size of array 'compile_type_assert' is negative

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build
Summary|libgcc2.c:1623: error: size |[4.0 only] libgcc2.c:1623:
   |of array|error: size of array
   |'compile_type_assert' is|'compile_type_assert' is
   |negative|negative
   Target Milestone|--- |4.0.1


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

[Bug c++/21306] [4.0 Regression] Another way to generate "inline function ‘A::~A()’ used but never defined" errors

[prw at ceiriog1 dot demon dot co dot uk]

--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk  
2005-04-30 21:01 ---
Created an attachment (id=8773)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8773&action=view)
Test case


-- 


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

[Bug c++/21306] New: [4.0 Regression] Another way to generate "inline function ‘A::~A()’ used but never defined" errors

[prw at ceiriog1 dot demon dot co dot uk]

The attached test case leads to this error:

[EMAIL PROTECTED] Orfeo]$ g++ main.ii
../../Orfeo/A.h:3: warning: inline function A::~A() used but never defined
/tmp/cc2W2kUK.o(.gnu.linkonce.t._ZN1BI1AED1Ev[B::~B()]+0xf): In function
`B::~B()':
: undefined reference to `A::~A()'
collect2: ld returned 1 exit status

This is a very simplified model of a bug which I have found when using
the STL vector template, which explicitly invokes a destructor via
p->~T().  The problem is that class A does not define an explicit
destructor, but the class B needs it.

This is a regression since 3.4.2 (or at least the Fedora Core version
gcc-3.4.2-6.fc3).  Running that on the same code, no destructor call
~A() is generated in ~B().  Presumably the compiler deduces that the
template class T(=A) has no nontrivial destructor in this case and so
optimizes out the call t->~T();

[Presumably an empty stub could be generated, but where?  In the
present example it is not generated since the filename for the #pragma
implementation (main.cc) does not match that for the #pragma interface
(A.h).  You might add an implementation file A.cc with a #pragma
implementation, but this does not help unless it contains an explicit
reference to ~A.  Otherwise it doesn't know that any such destructor
is needed.  The destructor would have to be generated at the point of
use, even though this may lead to some duplication between modules,
since there seems to be no way of deducing the "correct" place to put
it.]

-- 
   Summary: [4.0 Regression] Another way to generate "inline
function ‘A::~A()’ used but never defined" errors
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prw at ceiriog1 dot demon dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,prw at ceiriog1 dot
demon dot co dot uk
 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=21306

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[jpr at essi dot fr]

--- Additional Comments From jpr at essi dot fr  2005-04-30 20:58 ---
Subject: Re:  Configuring g++ library for various locales
 ?

pcarlini at suse dot de wrote:

>--- Additional Comments From pcarlini at suse dot de  2005-04-30 19:54 
>---
>You are not telling us which is your target. I would guess it's not a GNU
>system and in that case unfortunately we cannot help you, at least not in the
>short term: named locales are currently supported only on GNU systems 
>(basically
>glibc makes the difference).
>
>  
>
My target is a Mandrake 10.1 distribution. This is what uname says

5-kheops% uname -a
Linux kheops.jpr.essi.fr 2.6.8.1-12mdk #1 Fri Oct 1 12:53:41 CEST 2004 
i686 Intel(R) Pentium(R) 4 CPU 2.40GHz unknown GNU/Linux
5-kheops%

and glibc is glibc-2.3.3-23.1.101mdk

Jean-Paul Rigault




-- 


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

[Bug target/20633] libgcc2.c:1623: error: size of array 'compile_type_assert' is negative

[gerald at pfeifer dot com]

--- Additional Comments From gerald at pfeifer dot com  2005-04-30 20:52 
---
I plan to commit this to the 4.0-branch a bit later, but surely in time for
the GCC 4.0.1 release.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |gerald at pfeifer dot com
   |dot org |
 Status|WAITING |ASSIGNED


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

[Bug libfortran/18958] eoshift segfaults when shifting off the end of an array

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-30 
20:51 ---
Subject: Bug 18958

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-30 20:51:39

Modified files:
libgfortran: libgfortran.h ChangeLog 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: eoshift.f90 

Log message:
2005-04-30  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/18958
libgfortran.h:  Change typedef of index_type from size_t
to ssize_t.

2005-04-30  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/18958
* gfortran.dg/eoshift.f90:  New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gcc&r1=1.23&r2=1.24
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.206&r2=1.207
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5419&r2=1.5420
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eoshift.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/21305] New: flag_delete_null_pointer_checks is target specific

[roger at eyesopen dot com]

The current -fdelete_null_pointer_checks implementation makes assumptions that
the target processor will trap on reads or writes to address zero.  
Unfortunately,
these assumptions are target (often operating system) specific.

Here's a test case for AIX:

void abort();

int test(char *ptr)
{
  int x = *ptr;
  return ptr ? x+1: 2;
}

int main()
{
  if(test(0) != 2)
abort();
}

When compiled with mainline this aborts when compiled at -O2 or higher, and
passes when compiled at -O1 or lower.  AIX allows reads from but not writes
to address zero.  Other targets, specifically those without virtual memory
often allow both reading and writing to address zero.

I propose we should add target macros, TARGET_NULL_POINTER_READABLE and
TARGET_NULL_POINTER_WRITABLE and control the effects of the
-fdelete_null_pointer_checks with that.  The current situation is that
these transformations are enabled automatically at -O2 without regard to
the target environment.

-- 
   Summary: flag_delete_null_pointer_checks is target specific
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-ibm-aix5.2.0.0


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

[Bug tree-optimization/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-04-30 20:47 
---
cxg2009 is no longer failing, it started to PASS between

LAST_UPDATED: Tue Apr 26 21:38:28 UTC 2005
LAST_UPDATED: Sat Apr 30 15:50:39 UTC 2005

Still same ICE on cxh1001.

-- 
   What|Removed |Added

Summary|[4.1 Regression] ACATs ICE  |[4.1 Regression] ACATs ICE
   |cxg2009 and cxh1001 at tree-|cxh1001 at tree-vrp.c:124
   |vrp.c:124   |


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

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-04-30 
20:46 ---
Andrew is right, this error usually means that a shared library contains code
that has not been compiled with -fPIC.  The Solaris 64-bit runtime linker
doesn't seem to be able to cope with this (unlike the 32-bit one).

Does it change anything if you build libq.so with -mimpure-text?


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|critical|normal
  Component|c++ |target
  GCC build triplet||sparc64-sun-solaris2.*
   GCC host triplet||sparc64-sun-solaris2.*
 GCC target triplet||sparc64-sun-solaris2.*
   Priority|P3  |P2
Summary|gcc 4.0 fails to statically |Runtime error with C++
   |link on Solaris SPARC 64 bit|shared library and --
   ||disable-shared


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

[Bug target/20633] libgcc2.c:1623: error: size of array 'compile_type_assert' is negative

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-30 
20:38 ---
Subject: Bug 20633

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-30 20:38:46

Modified files:
gcc: ChangeLog 
gcc/config : freebsd-spec.h 

Log message:
PR bootstrap/20633
* config/freebsd-spec.h (FBSD_CPP_SPEC): Add %(cpp_arch).

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8541&r2=2.8542
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/freebsd-spec.h.diff?cvsroot=gcc&r1=1.13&r2=1.14



-- 


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
20:25 ---
The profile at -O2, says that may_alias is taking 50% of the time and this is 
with "4.1.0 20050323".

-- 
   What|Removed |Added

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


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
20:19 ---
For a profile on ppc-darwin at -O0 we see that a lot (10% or so) of the time is 
spent in reload or 
walk_tree

-- 


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|middle-end  |c++


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

[Bug middle-end/21304] very long compile times with large cpp file from kdebindings

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |middle-end
   Keywords||compile-time-hog


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

[Bug c++/13578] [3.3 Regression] ICE in lookup_template_class

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
19:57 ---
*** Bug 21301 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jorgen at fabeljet dot com


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

[Bug c++/21301] Internal compiler error in cp/pt.c:4249, g++ cygwin 3.3.3-3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
19:57 ---
Fixed for 3.4.0 and above.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/21304] very long compile times with large cpp file from kdebindings

[olh at suse dot de]

--- Additional Comments From olh at suse dot de  2005-04-30 19:54 ---
Created an attachment (id=8772)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8772&action=view)
sipqtpart0.ii.bz2


-- 


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

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-30 19:54 
---
You are not telling us which is your target. I would guess it's not a GNU
system and in that case unfortunately we cannot help you, at least not in the
short term: named locales are currently supported only on GNU systems (basically
glibc makes the difference).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/21304] New: very long compile times with large cpp file from kdebindings

[olh at suse dot de]

compiling kdebindings hangs after a while.
the attached testcase (680k) takes a very long time to compile.

[EMAIL PROTECTED]:~> /usr/bin/time 
./install_gcc41-1-O1/libexec/gcc/powerpc-unknown-linux-gnu/4.1.0/cc1plus 
-fpreprocessed /tmp/sipqtpart0.ii -quiet -dumpbase sipqtpart0.cpp 
-auxbase-strip sipqtpart0.o -O2 -O2 -Wall -Wall -Wall -W -version 
-fmessage-length=0 -fPIC -fmessage-length=0 -o sipqtpart0.s -O2 -v
ignoring nonexistent directory 
"/home/abuild/install_gcc41-1-O1/lib/gcc/powerpc-unknown-linux-gnu/4.1.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 
/home/abuild/install_gcc41-1-O1/lib/gcc/powerpc-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0
 
/home/abuild/install_gcc41-1-O1/lib/gcc/powerpc-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0/powerpc-unknown-linux-gnu
 
/home/abuild/install_gcc41-1-O1/lib/gcc/powerpc-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward
 /usr/local/include
 /home/abuild/install_gcc41-1-O1/include
 /home/abuild/install_gcc41-1-O1/lib/gcc/powerpc-unknown-linux-gnu/4.1.0/include
 /usr/include
End of search list.
GNU C++ version 4.1.0 20050429 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.1.0 20050429 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/usr/lib/qt3/include/qnetworkprotocol.h:58: warning: 'class 
QNetworkProtocolFactoryBase' has virtual functions but non-virtual destructor
/usr/lib/qt3/include/qtooltip.h:86: warning: 'class QToolTip' has virtual 
functions but non-virtual destructor
/usr/lib/qt3/include/qfiledialog.h:78: warning: 'class QFilePreview' has 
virtual functions but non-virtual destructor
16616.21user 2.85system 4:37:01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+275763minor)pagefaults 0swaps

gcc 4.0 -O0  == 0:02:15 h:mm:ss
gcc 4.0 -O1  == 1:06:00
gcc 4.0 -O2  == 4:05:00
gcc 4.1 -O2  == 4:37:00 

This is on a 1.5GHz POWER5.

./install_gcc40-1-O1/bin/g++ -v
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: /home/abuild/src/gcc-4_0-branch/configure 
--prefix=/home/abuild/install_gcc40-1-O1 --enable-threads=posix 
--enable-languages=c,c++ --enable-checking --with-system-zlib --enable-shared 
--enable-__cxa_atexit --disable-nls
Thread model: posix
gcc version 4.0.1 20050429 (prerelease)

I'm trying mainline with --disable-checking at the moment.

-- 
   Summary: very long compile times with large cpp file from
kdebindings
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olh at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-linux
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux


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

[Bug fortran/21300] ICE: Segmentation fault in gfc_trans_subcomponent_assign

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
19:45 ---
(In reply to comment #2)
> I think there is another bug which will block OrbFit compiling, I will see if 
> I can reduce that one too.

Note I filed PR 21301 and bug 21302 for those issues.

-- 


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

[Bug fortran/21303] New: "Positive width required in format string"

[pinskia at gcc dot gnu dot org]

Another bug while compiling OrbFit.
299 FORMAT('Scaling LOV=',L/'Second  LOV=',L)

END

ICC 8.1 accepts this.

-- 
   Summary: "Positive width required in format string"
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: fortran
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=21303

[Bug fortran/21302] New: Max line length in free form mode

[pinskia at gcc dot gnu dot org]

I don't know if this is not a bug but I found this will looking into 21300, 
take the following Fortran free 
formed code:
 if 
(abs(aa).gt.999.d0.or.abs(bb).gt.99
9.d0.or.abs().gt.999.d0) THEN
endif
 
 end program

Note the if is all on the same line.
We get an error (and a warning with -Wline-truncation) but I don't think free 
form should have a line 
lenght limit.

-- 
   Summary: Max line length in free form mode
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: fortran
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=21302

[Bug fortran/21300] ICE: Segmentation fault in gfc_trans_subcomponent_assign

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
19:00 ---
Confirmed, reduced testcase:
TYPE ast_obs
   DOUBLE PRECISION, DIMENSION(:), POINTER :: geopos
END TYPE ast_obs
TYPE(ast_obs), PARAMETER :: undefined_ast_obs = AST_OBS(NULL()) 

CONTAINS

SUBROUTINE read_rwo_rec()
  TYPE(ast_obs)  :: obs1
  obs1=undefined_ast_obs
  RETURN
END SUBROUTINE read_rwo_rec

END

I think there is another bug which will block OrbFit compiling, I will see if I 
can reduce that one too.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-30 19:00:44
   date||


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

[Bug c++/21301] Internal compiler error in cp/pt.c:4249, g++ cygwin 3.3.3-3

[jorgen at fabeljet dot com]

--- Additional Comments From jorgen at fabeljet dot com  2005-04-30 18:50 
---
Created an attachment (id=8771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8771&action=view)
Preprocessed compiler input


-- 


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

[Bug c++/21301] New: Internal compiler error in cp/pt.c:4249, g++ cygwin 3.3.3-3

[jorgen at fabeljet dot com]

the exact version of GCC; the system type; the options given when GCC was
configured/built;
---
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/l
ib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc,
pascal --enable-nls --without-included-gettext --enable-libgcj
--with-system-zlib --enable-interpreter --enable-threads=
posix --enable-java-gc=boehm --enable-sjlj-exceptions
--disable-version-specific-runtime-libs --disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
---

the complete command line that triggers the bug; the compiler output (error
messages, warnings, etc.);
---
g++ -Wall -W -g3 -o0 -ggdb -L/cygdrive/k/workdir/build
-I/cygdrive/k/kildekode/dat2b/src/include -I/cygdrive/k/kildekode
/dat2b/tools/util `/cygdrive/k/workdir/bin/cppunit-config --cflags` --save-temps
-c hash_table_basics.cc -o /cygdrive/k/
workdir/build/hash_table_basics.o
/cygdrive/k/kildekode/dat2b/src/include/hasher_factory.h: In instantiation of
`universal_hasher_factory':
/cygdrive/k/kildekode/dat2b/src/include/linear_hashing_storage_policy.h:28:  
instantiated from `linear_hashing_storage_
policy, universal_hasher_factory,
std::equal_to, std::allocator >, linear_hashing_compartment > >'
/cygdrive/k/kildekode/dat2b/src/include/hash_table.h:62:   instantiated from
`hash_table, std::equal_to >,
std::allocator, linear_hashing
_storage_policy,
universal_hasher_factory, std::equal_to, std::all
ocator >,
linear_hashing_compartment > > >'
hash_table_basics.cc:36:   instantiated from `HashTableBasics'
/cygdrive/k/workdir/include/cppunit/extensions/TestSuiteFactory.h:20:  
instantiated from `CppUnit::Test* CppUnit::TestS
uiteFactory::makeTest() [with TestCaseType =
HashTableBasics]'
/cygdrive/k/workdir/include/cppunit/extensions/TestSuiteBuilderContext.h:91:  
instantiated from here
/cygdrive/k/kildekode/dat2b/src/include/hasher_factory.h:95: internal compiler
error: in
   lookup_template_class, at cp/pt.c:4249
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [/cygdrive/k/workdir/build/hash_table_basics.o] Error 1
---

(Giving some documentation as to what goes into the Host/Target/Build triplet
fields would be helpful to novice bug-submitters. The word "triplet" does not
occur in .)

-- 
   Summary: Internal compiler error in cp/pt.c:4249, g++ cygwin
3.3.3-3
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorgen at fabeljet dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ???
  GCC host triplet: i686-pc-cygwin
GCC target triplet: ???


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

[Bug libstdc++/21295] Configuring g++ library for various locales ?

[jpr at essi dot fr]

--- Additional Comments From jpr at essi dot fr  2005-04-30 18:45 ---
Subject: Re:  Configuring g++ library for various locales
 ?

pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
>14:56 ---
>What option are you taking about?
>
>The standard way of changing the locale is either by the LC_*/LANG environment 
>variable or using the 
>locale class.
>
>  
>
I know that. I am precisely trying to use the locale class !

Here is my test program

//---
#include 
#include 
using namespace std;

int main(int argc, char *argv[])
{
char *loc = "";
if (argc > 1) loc = argv[1];

cout << "Trying locale : " << loc << endl;
locale::global(locale(loc));
return 0;
}
//---

If I compile it with g++-3.4 or g++-4.0.0, the compilation is fine, but 
at run time I get an std::runtime_error if I try any locale except C and 
POSIX ! For instance

5-kheops% locale fr_FR
Trying locale : fr_FR
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
zsh: abort  locale fr_FR
5-kheops%

or

5-kheops% locale de_DE
Trying locale : de_DE
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
zsh: abort  locale de_DE
5-kheops%

But, if I compile this programm with g++-3.3.2, it does not throw.  And 
the locales are corrrectly installed on my machine and setlocale() works 
with C...

Thus I guessed (maybe wrongly) that it had something to do with my 
configuration when building gcc-3.4 and gcc-4 ,

Any help would be appreciated.
Best regards

Jean-Paul Rigault





-- 


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

[Bug fortran/21300] ICE: Segmentation fault in gfc_trans_subcomponent_assign

[andrea at poisson dot phc dot unipi dot it]

--- Additional Comments From andrea at poisson dot phc dot unipi dot it  
2005-04-30 18:21 ---
Created an attachment (id=8770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8770&action=view)
source file causing ICE

Source file causing ICE.
It's part of the OrbFit Software Package available at
http://newton.dm.unipi.it/orbfit/

-- 


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

[Bug fortran/21300] New: ICE: Segmentation fault in gfc_trans_subcomponent_assign

[andrea at poisson dot phc dot unipi dot it]

[EMAIL PROTECTED]:~/gcc/OrbFit3.2/src/suit$ gfortran -I../include -c
astrometric_observations.f90
astrometric_observations.f90: In function 'jplradar_transform':
astrometric_observations.f90:1679: 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.

gcc version:

Configured with: ../gcc-4.1-20050424/configure --enable-checking
--enable-languages=c,f95 : (reconfigured) ../gcc-4.1-20050424/configure
--enable-checking --enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050424 (experimental)

here is a backtrace:

#0  0x080c40ff in gfc_trans_subcomponent_assign (dest=0x403c4a28, cm=0x88e3e98,
expr=0x89830a8)
at ../../gcc-4.1-20050424/gcc/fortran/trans-expr.c:1598
#1  0x080c43d1 in gfc_trans_structure_assign (dest=0x40640ca8, expr=0x8981b78)
at ../../gcc-4.1-20050424/gcc/fortran/trans-expr.c:1673
#2  0x080c44c0 in gfc_conv_structure (se=0xbfffde9c, expr=0x8981b78, init=0)
at ../../gcc-4.1-20050424/gcc/fortran/trans-expr.c:1701
#3  0x080c49c6 in gfc_conv_expr (se=0xbfffde9c, expr=0x8981b78)
at ../../gcc-4.1-20050424/gcc/fortran/trans-expr.c:1798
#4  0x080c578e in gfc_trans_assignment (expr1=0x8981b28, expr2=0x8981b78)
at ../../gcc-4.1-20050424/gcc/fortran/trans-expr.c:2171
#5  0x080c5a59 in gfc_trans_assign (code=0x89830f8) at
../../gcc-4.1-20050424/gcc/fortran/trans-expr.c:2233
#6  0x080ab3c3 in gfc_trans_code (code=0x89830f8) at
../../gcc-4.1-20050424/gcc/fortran/trans.c:493
#7  0x080bfe9b in gfc_generate_function_code (ns=0x897d810)
at ../../gcc-4.1-20050424/gcc/fortran/trans-decl.c:2234
#8  0x080ab953 in gfc_generate_module_code (ns=0x88dfe10) at
../../gcc-4.1-20050424/gcc/fortran/trans.c:706
#9  0x0808a22d in gfc_parse_file () at
../../gcc-4.1-20050424/gcc/fortran/parse.c:2629
#10 0x080a4ddd in gfc_be_parse_file (set_yydebug=0) at
../../gcc-4.1-20050424/gcc/fortran/f95-lang.c:263
#11 0x085714b2 in compile_file () at ../../gcc-4.1-20050424/gcc/toplev.c:1000
#12 0x08572d32 in do_compile () at ../../gcc-4.1-20050424/gcc/toplev.c:2120
#13 0x08572d97 in toplev_main (argc=3, argv=0xbfffe154) at
../../gcc-4.1-20050424/gcc/toplev.c:2152
#14 0x080e0d02 in main (argc=3, argv=0xbfffe154) at
../../gcc-4.1-20050424/gcc/main.c:35

listing:

1593{
1594  /* Array pointer.  */
1595  if (expr->expr_type == EXPR_NULL)
1596{
1597  dest = gfc_conv_descriptor_data (dest);
1598  tmp = fold_convert (TREE_TYPE (se.expr),
1599  null_pointer_node);
1600  gfc_add_modify_expr (&block, dest, tmp);
1601}
1602  else

TREE_TYPE(se.expr) causes segfault since se is just initialized to zero (line 
1590).

-- 
   Summary: ICE: Segmentation fault in gfc_trans_subcomponent_assign
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrea at poisson dot phc dot unipi dot it
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/21236] force_gimple_operand destroys trees passed to it

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
17:59 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-30 17:59:12
   date||


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

[Bug debug/21022] [4.0 only] ICE while compiling GdkFontMetrics.class with stabs debugging

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
17:57 ---
*** Bug 20910 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||steve at netfuel dot com


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

[Bug java/20910] gcc-4_0-brach GCJ ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
17:57 ---
This is fixed in 4.0.1.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 
17:54 ---
The reduced testcase in Comment #7 still ICEs. 

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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