[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[bonzini at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2004-10-18 14:06:18 |2004-10-19 07:35:57
   date||


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

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-10-19 07:42 
---
The fix is obvious, I misordered the two precedence in enum cp_parser_prec. 
I'll commit it and add a testcase.

-- 


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

[Bug c++/18053] New: __gnu_cxx::hash_set uses return type of A::operator&() instead of A

[j at zsch dot de]

struct A 
{
// ...
B* operator&();
operator B() const;
};

__gnu_cxx::hash_set stores values of B, the return type of operator&(). It 
should store values of A as the similar hash_map does.

The following example shows the effect. hash_set doesn't use copy constructor 
of A, instead it calls A::operator int(). When retrieving values, the iterator 
pretends to deliver A, but in real it delivers int. A::print() doesn't print 
the values _a2=1000 and 2000.

Nevertheless hash_set::value_type seems to be A (not int).



#include 
#include 
#include 

using namespace std;
using namespace __gnu_cxx;

#define WITH_SET_ERROR



struct A
{
A( int a, int a2 )
: 
_a(a)
, _a2(a2)
{ 
cout << "A(" << _a << ")\n"; 
}


A( const A& a )
: 
_a(a._a), 
_a2(a._a2) 
{ 
cout << "A(" << _a << ") copy\n"; 
}


~A()
{ 
cout << "~A(" << _a << ")\n"; 
}



void print() const
{ 
cout << _a << "," << _a2; 
}


bool operator==( const A& a ) const
{ 
return _a == a._a  &&  _a2 == a._a2; 
}


#ifdef WITH_SET_ERROR
int* operator&()
{ 
cout << "operator &() " << _a << "\n"; return &_a; 
}
#endif

operator int() const
{ 
cout << "operator int() " << _a << "\n"; 
return _a; 
}


int _a;
int _a2;
};


namespace __gnu_cxx
{
template<>
struct hash< A >
{
size_t operator() ( const A& a ) const  { return a._a; }
};
}



int main( int, char** )
{
A a ( 1, 1000 );
A b ( 2, 2000 );

cout << "a="; a.print(); cout << "\n";
cout << "b="; b.print(); cout << "\n";
  
{
cout << "\nset:\n";
typedef hash_set Set;
Set set;
set.insert( a );
set.insert( b );

for( Set::iterator it = set.begin(); it != set.end(); it++ )
{
it->print();  cout << "\n";
}
}

{
cout << "\nmap:\n";  // hash_map is ok
typedef hash_map Map;
Map map;
map[ a ] = true;
map[ b ] = true;

for( Map::iterator it = map.begin(); it != map.end(); it++ )
{
it->first.print();  cout << "\n";
}
}

cout << "\n";
}

-- 
   Summary: __gnu_cxx::hash_set uses return type of
A::operator&() instead of A
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at zsch dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/18054] New: Undefined reference to ~basic_iostream(), with -O[12]

[veksler at il dot ibm dot com]

This no-op code fails to link when compiled with optimizations enabled.
Trivial code fails with -O3, a bit more complex code will fail with -O[12] .
(Both examples are given below)

$ cat tO3.cpp
#include 
int main()
{
std::stringstream name;
name <
>::~basic_iostream()'
[repeating messages trimmed]

$ cat t.cpp
#include 
#include 

void NoAllocate()
{
if (false)
   std::allocator().allocate(1);
}

struct Contained
{
  Contained() { NoAllocate(); }
};

struct A
{
   Contained _parent;
};

inline void Nop() {}

int main()
{
std::stringstream name;
name <
>::~basic_iostream()'

[repeating messages trimmed]

$ /home/veksler/gcc-4.0-20041017/bin/g++ -v
Reading specs from
/home/veksler/gcc-4.0-20041017/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041017.src/configure
--prefix=/home/veksler/gcc-4.0-20041017 --enable-languages=c++
Thread model: posix
gcc version 4.0.0 20041017 (experimental)

$ rpm -q binutils
binutils-2.14.90.0.4-35

-- 
   Summary: Undefined reference to ~basic_iostream(),  with -O[12]
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: veksler at il dot ibm dot com
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=18054

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-19 09:10 ---
This problem is the same reported here:

  http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html

that nobody could reproduce on up to date setups (Jonathan included!). Could
you perhaps investigate further along these lines:

  http://gcc.gnu.org/ml/libstdc++/2004-09/msg00228.html

???
If nothing new and reproducible comes out, I'm afraid we have to close this
PR as "WORKSFORME". Thanks.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/18055] New: seems not possible to specialize a template member function

[ramya dot chandar at wipro dot com]

Environment : i686-pc-linux-gnu
Compiler Version: GCC 3.3.2 
Kernel Version  : 2.4.7-10

It seems, not possible to specialize a template member functions const. I got a
file(.impl) which got the following template functions( generalized and
specialized template functions ) and i got the corresponding header file ( where
this .impl file is getting included ).

IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);


But, the build is getting failed during linking stage with the below mentioned
error( for all the template functions ).

There is no problem with 2.95.3

Linking fails with the following error( for all the template functions ).

/cm4/fsn/app/asam/atm2/nt/../export/idl/AtmApplication_ifc.cc:344: undefined
reference to `IOCM_SequenceTempl::_size(void) const'
/cm4/fsn/app/asam/atm2/nt/../export/idl/AtmApplication_ifc.cc:349: undefined
reference to `IOCM_SequenceTempl::_pack(IOCM_MessageBox &)
const'

-- 
   Summary: seems not possible to specialize a template member
function
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramya dot chandar at wipro dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: Linux linux3 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686


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

[Bug c++/18056] New: seems not possible to specialize a template member function

[ramya dot chandar at wipro dot com]

Environment : i686-pc-linux-gnu
Compiler Version: GCC 3.3.2 
Kernel Version  : 2.4.7-10

It seems, not possible to specialize a template member functions const. I got a
file(.impl) which got the following template functions( generalized and
specialized template functions ) and i got the corresponding header file ( where
this .impl file is getting included ).

IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);
IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox);


But, the build is getting failed during linking stage with the below mentioned
error( for all the template functions ).

There is no problem with 2.95.3

Linking fails with the following error( for all the template functions ).

/cm4/fsn/app/asam/atm2/nt/../export/idl/AtmApplication_ifc.cc:344: undefined
reference to `IOCM_SequenceTempl::_size(void) const'
/cm4/fsn/app/asam/atm2/nt/../export/idl/AtmApplication_ifc.cc:349: undefined
reference to `IOCM_SequenceTempl::_pack(IOCM_MessageBox &)
const'

-- 
   Summary: seems not possible to specialize a template member
function
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramya dot chandar at wipro dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: Linux linux3 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686


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

[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-10-19 09:55 ---
Testcase from comment #9 and '-O2 -msse -fomit-frame-pointer' procduces code
that seems OK:

prepare:
pushl  %ebp
pushl  %edi
movl   $hmag+512, %edi
pushl  %esi
movl   $hphase, %esi
pushl  %ebx
movl   $hmag, %ebx
subl   $76, %esp
movss  .LC0, %xmm0
movl   96(%esp), %ebp
movaps %xmm0, 32(%esp)
.p2align 4,,15
.L2:
flds   (%ebx)
addl   $4, %ebx
fchs
flds   (%esi)
addl   $4, %esi
fstpl  (%esp)
fstpl  16(%esp)
call   sin
fldl   16(%esp)
cmpl   %ebx, %edi
fmulp  %st, %st(1)
fmull  .LC2
fstps  (%ebp)
jne.L2
addl   $76, %esp
popl   %ebx
popl   %esi
popl   %edi
popl   %ebp
ret

BTW: when alter_reg() for reg 81 is called from reload() (at line ~836,
reload1.c) it gets right offset (-32). [This offset is calculated at line ~1969
in reload1.c]. Something changes this correct offset from (-32) to (-56) if
frame pointer is not omitted.


-- 


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

[Bug middle-end/18005] [4.0 Regression] ICE with simple loop with VLA

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  2004-10-19 
10:03 ---
Subject: Re:  [4.0 Regression] ICE with simple loop with VLA

Patch is here:

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01592.html


-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[veksler at il dot ibm dot com]

--- Additional Comments From veksler at il dot ibm dot com  2004-10-19 11:01 
---
Yes, I do get the same errors as reported in 
http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html

Here is the offending symbol:
$ nm --demangle /home/veksler/gcc-4.0-20041017/lib/libstdc++.so | grep
' >::~basic_iostream
[in-charge deleting]()
0005ccd0 t std::basic_iostream >::~basic_iostream
[in-charge]()
0005cc40 t std::basic_iostream >::~basic_iostream
[not-in-charge]()


As you see, this symbol is local.

My compile was clean, no left overs from previous gcc compiles.

$ tar xjf gcc-4.0-20041017.tar.bz2
$ mv gcc-4.0-20041017 gcc-4.0-20041017.src
$ mkdir objs gcc-4.0-20041017
$ cd objs
$ ../gcc-4.0-20041017.src/configure --prefix=/home/veksler/gcc-4.0-20041017
--enable-languages=c++
$ make profiledbootstrap
** crash and burn 
$ cd .. ; rm -rf objs ; mkdir objs ; cd objs
$ ../gcc-4.0-20041017.src/configure --prefix=/home/veksler/gcc-4.0-20041017
--enable-languages=c++
$ make bootsrap
$ make install

Maybe profiledbootstrap trashed the source directory? If that is the case,
then the makefiles are way too buggy.

I'll try to re-create the source directory, and recompile. 

-- 


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

[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-19 11:06 
---
Same problem on amd64-*-* where the 32-bit libiberty.a is in $(PREFIX)/lib/32.


-- 
   What|Removed |Added

  GCC build triplet|sparc64-sun-solaris2.*  |sparc64-*-*, amd64-*-*
   GCC host triplet|sparc64-sun-solaris2.*  |sparc64-*-*, amd64-*-*
 GCC target triplet|sparc64-sun-solaris2.*  |sparc64-*-*, amd64-*-*


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

[Bug c++/18055] seems not possible to specialize a template member function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 11:27 
---
*** Bug 18056 has been marked as a duplicate of this bug. ***

-- 


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

[Bug c++/18056] seems not possible to specialize a template member function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 11:27 
---


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

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/18055] seems not possible to specialize a template member function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 11:27 
---
Can you attach the preprocessed source?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/18053] __gnu_cxx::hash_set uses return type of A::operator&() instead of A

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 11:35 
---
$ ../gcc-4.0-20041017.src/configure --prefix=/home/veksler/gcc-4.0-20041017
--enable-languages=c++

Can you try with --enable-__cxa_atexit ?

-- 


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

[Bug c++/13590] [3.3/3.4/4.0 regression] [DR39] Non-existing ambiguity when inhering through virtuals two identical using declarations.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 11:37 
---
Unsetting the target milestone as there is a stil opened DR about this.

-- 
   What|Removed |Added

  Known to fail|3.4.1 4.0   |3.4.1 4.0.0
   Target Milestone|4.0.0   |---


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

[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-19 11:42 
---
So, Eric, it looks like that adding -fomit-frame-pointer to your Makefile is a 
good workaround for the time being without losing any advanced optimization. 
You were looking for one, IIRC.

-- 


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

[Bug c++/18055] seems not possible to specialize a template member function

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-19 11:46 
---
I fixed a similar bug in 4.0 already, but we can't really tell until either you 
try for yourself or attacch a preprocessed file.

-- 


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

[Bug libstdc++/18053] __gnu_cxx::hash_set uses return type of A::operator&() instead of A

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-19 12:08 ---
More about this issue later, only two quick remarks:
1- Current mainline doesn't even compile the testcase, due to type mismatches
in the allocator caused by the overloaded operators.
2- In any case, it's unlikely that more-than-trivial changes will go in for the
hash_* extensions, since we are in the process of adding the new unordered
containers in "tr1", which will provide similar functionalities in a portable
way. For more info see, f.i., N1687 in:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/

-- 


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

[Bug c/18057] New: strange warning

[etienne_lorrain at yahoo dot fr]

With the latest version bootstrapped on PC debian:
$ /home/etienne/projet/toolchain/bin/gcc -v
Reading specs from /home/etienne/projet/toolchain/lib/gcc/i686-pc-linux-
gnu/4.0.0/specs
Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-
languages=c
Thread model: posix
gcc version 4.0.0 20041017 (experimental)

   compiling this code:
typedef struct {
unsignedlimit : 16;
unsignedbase : 24;
unsignedaccessed : 1;   /* if 1 */
unsignedwritable : 1;   /* if 1 */
unsignedexpansion_direction : 1;/* down if 1 */
unsignedcste_10 : 2;
unsigneddpl : 2;
unsignedpresent : 1;
unsignedlimit_msb : 4;
unsignedavailable : 1;
unsignedcste_0 : 1;
unsignedbig : 1;
unsignedgranularity : 1;
unsignedbase_msb : 8;
} __attribute__ ((packed)) dataseg_t;

dataseg_t dataseg = {
  .limit= 0x,
  .base = 0,
  .accessed = 1,
  .writable = 1,
  .cste_10  = 2,
  .present  = 1,
  .limit_msb= 0xFF,
  .big  = 0,
  .granularity  = 1
};

  leads to this warning (line of .limit_msb):
$ /home/etienne/projet/toolchain/bin/gcc -Os -c tmp.c
tmp.c:25: warning: large integer implicitly truncated to unsigned type

  Etienne.

-- 
   Summary: strange warning
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
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=18057

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-19 12:40 
---
Subject: Bug 18047

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-19 12:40:32

Modified files:
gcc/cp : ChangeLog parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/parse: expr3.C 

Log message:
2004-10-19  Paolo Bonzini  <[EMAIL PROTECTED]>

PR c++/18047
* parser.c (enum cp_parser_prec): Give relational expressions
a higher precedence than equality expressions.

2004-10-19  Paolo Bonzini  <[EMAIL PROTECTED]>

PR c++/18047

* g++.dg/parse/expr3.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4442&r2=1.4443
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.265&r2=1.266
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4473&r2=1.4474
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/expr3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-10-19 12:43 
---
Fixed by the above patch.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/18057] strange warning

[etienne_lorrain at yahoo dot fr]

--- Additional Comments From etienne_lorrain at yahoo dot fr  2004-10-19 12:47 
---
  Well, sometimes you are sure the field is 8 bits wide,
 limit_msb is only 4 bits unlike base_msb.
 A "value does not fit the size" would be better, but ...

  Sorry,
  Etienne.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 12:51 
---
I also cannot reproduce it:
GNU C++ version 4.0.0 20041018 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20041018 (experimental).

GNU assembler version 2.15.90.0.3 (i386-redhat-linux) using BFD version 2.15.90.0.3 
20040415

-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 12:54 
---
Here is how I configured my GCC:
Configured with: /home/gates/pinskia/src/gnu/gcc/src/configure 
--target=i686-pc-linux-gnu --
host=i686-pc-linux-gnu --enable-__cxa_atexit --enable-languages=c++,objc,java 
--prefix=/home/
gates/pinskia/linux --enable-threads=posix --enable-shared

-- 


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

[Bug c++/9634] [3.4/4.0 regression] [DR224] Injected class name as qualifier should not make the name dependent

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 12:57 
---
Removing the target milestone because the DR is questionable.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug bootstrap/18058] New: Sun CC cannot bootstrap GCC (static inline)

[ebotcazou at gcc dot gnu dot org]

The error message is:

cc -erroff -c   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I/home/eric/cvs/gcc/gcc
-I/home/eric/cvs/gcc/gcc/build -I/home/eric/cvs/gcc/gcc/../include -I./../intl
-I/home/eric/cvs/gcc/gcc/../libcpp/include -I/opt/build/eric/local/include
-I/opt/build/eric/local/include \
 -o build/insn-conditions.o insn-conditions.c
cc -erroff   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genflags \
build/genflags.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/min-insn-modes.o build/gensupport.o build/insn-conditions.o
build/print-rtl.o \
build/errors.o ../build-sparc-sun-solaris2.7/libiberty/libiberty.a
ild: (undefined symbol) bitmap_zero_bits -- referenced in the text segment of
build/insn-conditions.o
ild: (undefined symbol) vec_gc_p_reserve -- referenced in the text segment of
build/insn-conditions.o
ild: (undefined symbol) vec_gc_free -- referenced in the text segment of
build/insn-conditions.o
gmake[2]: *** [build/genflags] Error 5
gmake[2]: Leaving directory `/opt/build/eric/gcc/gcc'
gmake[1]: *** [stage1_build] Error 2
gmake[1]: Leaving directory `/opt/build/eric/gcc/gcc'
gmake: *** [bootstrap] Error 2

This is reproducible with GCC as the bootstrap compiler if it is invoked with
-fkeep-inline-functions.

-- 
   Summary: Sun CC cannot bootstrap GCC (static inline)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-solaris2.*
  GCC host triplet: *-*-solaris2.*
GCC target triplet: *-*-solaris2.*


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

[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 13:05 
---
For the bitmap problem, the header comes in from basic-block.h via regs.h.

Maybe we should have #ifndef BUILD (or what ever is the macro).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2004-10-19 13:05:48
   date||
Summary|Sun CC cannot bootstrap GCC |[4.0 Regression] Sun CC
   |(static inline) |cannot bootstrap GCC (static
   ||inline)
   Target Milestone|--- |4.0.0


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

[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 13:06 
---
The vec problem might be the same issue.  I will look into it.

-- 


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

[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 13:26 
---
Created an attachment (id=7377)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7377&action=view)
patch which should fix this

This works for me, at least with -fkeep-inline-functions.
Can you try it and see if it works for you?

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[veksler at il dot ibm dot com]

--- Additional Comments From veksler at il dot ibm dot com  2004-10-19 13:32 
---
Subject: Re:  Undefined reference to ~basic_iostream(),  with -O[12]


To summarize the difference between our setups:

My setup (that fails):
- binutils-2.14.90.0.4-35
- No special configure --enable flags (except enable-languages=c++)

Your setup (that works):
- binutils-2.15.90.0.3
- configure with: --enable-threads=posix--enable-__cxa_atexit
   [ and enable-languages + enable-shared]


I untarred, and compiled a clean gcc just to make sure - and it still fails
(with my config flags).
I'll try your config flags next to see if it still fails - I have to go,
results will be available only after 16 hours.




-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-19 13:39 ---
By the way, --enable-__cxa_atexit is most certainly *not* involved, since many
people test daily without passing it and everything is fine.

-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-19 13:53 
---
Just for the record: I can reproduce the problem with gcc-4.0-20041019
on i686-pc-linux-gnu, configured with: --enable-threads --enable-checking

Enabling __cxa_atexit or not does not make a difference.
Binutils version is 2.14.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 13:58 
---
Maybe this is a binutils bug:
tin:~>nm --demangle ~/linux/lib/libstdc++.so.6.0.3 | grep ' >::~basic_iostream()
0005cfd0 W std::basic_iostream >::~basic_iostream()
0005cf40 W std::basic_iostream >::~basic_iostream()



-- 


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

RE: getting memory errors when natively bulding native gnu gcc 3. 3.2 compiler on PQ2FADS-VR with 32 MB DRAM memory

[Povolotsky, Alexander]

I (may be being naive, but at least with good intensions ;-) )
would like to consider this as a problem (bug ?) - in two areas:

1) Gnu gcc area:

   a) At best - Gnu ggc folks need to attempt to overall improve (minimize)
memory consumption
  for 3.3.x and 3.4.x gcc builds
   b) Less desirable - Gnu ggc folks need to improve configuration options
and/or decrease memory consumption
  in  "partial" (for example language-wise) builds
   c) Also (IMHO) Gnu gcc folks need to provide option for doing "slower" (
more iterative ?) gcc build process
  but with guaranteed low memory consumption
   d) At the very least - Gnu gcc folks need to clearly document current
memory consumption reqs for
  3.2.x, 3.3.x, 3.4.x .

2) Kernel area (this is subject of discussion - please consider below as
just a guess talking point ...)

   a) Improve/optimize 2.6 kernel swapper functionality in general (? )
   
   b) Fix (if this does not really work ?) 
   >swap has to be on a directly attached storage device.  At least, I've
   >never been able to make swapping over NFS work.

Constructive responses are welcomed !

Thanks,
Best Regards,
Alex

-Original Message-
From: Kai Ruottu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 3:37 AM
To: Lennert Buytenhek
Cc: Povolotsky, Alexander; crossgcc
Subject: Re: getting memory errors when natively bulding native gnu gcc
3.3.2 compiler on PQ2FADS-VR with 32 MB DRAM memory

Lennert Buytenhek wrote:

> On Sun, Oct 17, 2004 at 11:19:51AM -0400, Povolotsky, Alexander wrote:
>>Out of Memory: Killed process 9807 (cc1).
>>powerpc-linux-gcc-3.3.2: Internal error: Terminated (program cc1)
> 
> You ran out of memory, and the kernel had to kill your cc1 process.
> 
> Nothing you can do about that really, apart from adding memory or
> adding swap.

  The amount of memory required for running software seems to follow
something
like "The Law of More"... In early 80's 64 kbytes was enough, in late 80's
640
kbytes, in early 90's 6.4 Mbytes, in late 90's 64 Mbytes and now in early
2000's
this seems to be 640 Mbytes...

  Using 'top -b' during the GCC-build and then grep'ing the 'cc1' process
values
from the logfile, then sort'ing it, I got the following max memory needs for
the
gcc-3.2.3 when building the gcc-3.2.3 sources :

  3747 root  25   0 24436  23M  3856 R99,6  4,7   1:31 cc1
  3747 root  25   0 24012  23M  3744 R99,6  4,6   1:21 cc1
  3747 root  25   0 23032  22M  3796 R99,6  4,4   1:26 cc1
  3747 root  25   0 22804  22M  3744 R99,5  4,4   1:16 cc1

  So 23 Mbytes was required for this compile. Meanwhile for the newer
gcc-3.3.5
when compiling the gcc-3.3.5 sources I got something much bigger :

26227 root  25   0  114M 114M  3804 R99,3 22,7   1:25 cc1
26227 root  25   0  113M 113M  3852 R99,4 22,6   1:30 cc1
26227 root  25   0  113M 113M  3776 R99,4 22,6   1:20 cc1
26227 root  25   0  108M 108M  3688 R99,3 21,6   1:15 cc1

  This was tested with a RedHat 7.3 target cross-toolchain being for the
host and
'i486-linux-gnu' being the target, on my RedHat 8.0 build system.

  So, with gcc-3.2.x having 64 Mbytes or even only 32 Mbytes on the build
system
could be enough, but this isn't the case with gcc-3.3.x any more. One can
only
try to guess what the gcc-3.4.x and the under-construction gcc-4.x could
then 
require... Maybe the current 512 Mbytes in my build system isn't enough.

  If one thinks gcc-3.2.x being good enough, then maybe something can be
done with this issue...  Is there some serious problem with gcc-3.2.x and
Linux/PPC ?  The RedHat 8.0 and AFAIK the RedHat 9.0 came with gcc-3.2.x,
maybe SuSE 9.0 etc., so with x86 there seemingly was no problems

  If one has only 32 or 64 Mbytes on the target board but wants to try
building 
GCC natively, maybe the general advice would be to forget gcc-3.3.x and
newer
GCCs and use some earlier GCC with its much smaller memory requirements...
I really had suspected something like this when things suddenly didn't seem
to
work on the old 64 Mbyte PCs... In late 80's having 5 + 8 = 13 Mbytes in a
VAX
was really much memory and having 64 Mbytes in a PC and so being capable to
do
things one could earlier do only in mainframes, was something which could be
told in news (some Finnish research organization for agriculture moved their
statistical jobs to a PC from a mainframe...). But is this current or
"Really
Soon Now" need for 640 Mbytes memory for building GCC really what the GCC
users
will want, or only what the memory makers will want?

  I really thought it should still be possible to build (in reasonable time)
GCCs
in those 5 - 10 years old PCs with only 64 Mbyte memory (4 x 16 MB SIMM)...

Cheers, Kai

-Original Message-
From: Povolotsky, Alexander 
Sent: Sunday, October 17, 2004 11:20 AM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Cc: 'Bill Davidsen'; 'Kai Ruottu'; 'Dan Kegel'; 'bertrand marquis';
'Kumar Gala'; 'Robb, Sam'; 'Martin Schaffner'

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-19 14:03 ---
Yes, I'm also tempted to think it's a binutils bug (not so frequent on x86! ;)
People (libstdc++-v3 developers) using current binutils, 2.15 series, never report
it, apparently.

-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 14:05 
---
Just a note, my binutils is from FC2:
tin:~/src/gnu/gcctest>rpm -q binutils
binutils-2.15.90.0.3-5

-- 


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

[Bug tree-optimization/17986] [4.0 Regression] Compile error for make.adb breaks bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-19 15:03 
---
The file still takes a few minutes to compile but the situation has improved
since all the gnattools build for me as of today, both on sparc-sun-solaris2.8
and i586-mandrake-linux-gnu, whereas they previously didn't.  Could you try
again with an updated tree?


-- 
   What|Removed |Added

 Status|NEW |WAITING


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

[Bug fortran/16648] [gfortran] Does not support FLUSH intrinsic.

[coyote at coyotegulch dot com]

--- Additional Comments From coyote at coyotegulch dot com  2004-10-19 15:24 
---
(In reply to comment #2)
> gfortran is missing 87 non-standard intrinsic functions and subroutines
> from g77 runtime library.  I'll post the complete to fortran@ this weekend.

Was that list ever posted?

And has someone done a similar list for ISO 2003 (even though we still have a
ways to go on F95...)?

-- 


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

[Bug c/18059] New: bad diagnostic formatting

[nathan at gcc dot gnu dot org]

c-common.c contains
  void c_parse_error (const char *msgid, enum cpp_ttype token, tree value)

which purports to format msgid, however, it contains things like,
   error ("%s at end of input", string);
thus any magic %< in MSGID do not get munged.  Resulting in,
 error: expected %<,%> or %<...%> before '>' token

There needs to be a nesting mechanism to pass a format string as a % escape.

-- 
   Summary: bad diagnostic formatting
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathan 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=18059

[Bug c/18059] bad diagnostic formatting

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 15:56 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/17852] [4.0 Regression] weird quoting with synax error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 15:56 
---
*** Bug 18059 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

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


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

[Bug c++/18060] New: sprintf round problem (that not occurs with egcs)

[mauro at altersoft dot com dot ar]

I've read that you do not consider proper reporting bugs about rounding, but I
have a program compiled in a RH62 with egcs that works fine and the same program
compiled in RH73 with gcc making trouble.

Simple code line:

char aux[50];
char aux2[50];
sprintf(aux,"%.0f",2068.5);
sprintf(aux2,"%.0f",2067.5);

In RH73 gives in both cases "2068" !!  In RH62 aux is "2069" !

So I have to think that gcc has a problem that egcs does not.

-- 
   Summary: sprintf round problem (that not occurs with egcs)
   Product: gcc
   Version: 2.96 (redhat)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mauro at altersoft dot com dot ar
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18060] sprintf round problem (that not occurs with egcs)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 16:30 
---
Not a GCC bug, if it is a bug, it is a bug in glibc and not gcc.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-19 16:38 
---
Really looks like a binutils bug.
I just installed plain 2.14 and 2.15 binutils and bootstrapped the compiler
with --enable-languages=c++.

With binutils 2.14 I get the linker failures.
With 2.15 the program links fine.

Btw, nm --demangle from 2.14 doesn't show the destructors ~basic_iostream
for char in various versions of libstdc++ that are installed on my machine.
I only see their wchar_t counterparts. But with 2.15 they get listed.

But what are we going to do now?
Add some comment to our texinfo/online documentation?
E.g. something in install/specific.html?


-- 


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

[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts

[matz at suse dot de]

--- Additional Comments From matz at suse dot de  2004-10-19 16:46 ---
Does this go away with "--param iv-consider-all-candidates-bound=70" ? 
(Or with a higher number like 100 or 1000) 

-- 
   What|Removed |Added

 CC||matz at suse dot de


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

[Bug c++/18061] New: Problem with template class

[ycollet at freesurf dot fr]

When I compile this sample (g++ main.cpp -o main)
g++ says that A_val is not defined !
It uses to work with g++ version < 3.4

A.hpp 

template 
class A
{
public:
double getA() {return A_val;}
protected:
double A_val;
};


B.hpp ---

#include "A.hpp"

template
class B : public A
{
public:
double getB() {return A_val;}
protected:
double B_val;
};

main.cpp 

#include "B.hpp"

int main()
{
B test;

test.getA();

return 0;
}



-- 
   Summary: Problem with template class
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ycollet at freesurf dot fr
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: linux i686 gnu


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

[Bug c++/18061] Problem with template class

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 16:48 
---
Invalid, did you read the release notes?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/17265] [4.0 Regression] Libjava doesn't build

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-19 16:48 
---
Reverting the parse.y changes doesn't help.  The problem is that the inline
methods defined in java/lang/class.h are not emitted in natClass.o, despite the
presence of

#pragma implementation "Class.h"

at the beginning of the file.


-- 


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

[Bug java/17265] [4.0 Regression] Libjava doesn't build

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 16:51 
---
That sounds like C++ bug.

-- 


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

[Bug bootstrap/18062] New: Bootstrap with GCC 2.8.1 and CFLASG="-I${HOME}/include" and config.h in ~/include is broken

[v dot haisman at sh dot cvut dot cz]

This is a sample of build command and its verbose output with GCC 4.0.0. There
is -I/home/4/wilx/include on the command line. Notice the ordering of include
paths int its output:

[EMAIL PROTECTED]:::~/tmp/gcc-head/objdir/gcc> gcc -v -c   -g -DENABLE_CHECKING
-DENABLE_ASSERT_CHECKING -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -fno-common   -DHAVE_CONFIG_H -I/home/4/wilx/include  
-I. -I. -I../../srcdir/gcc -I../../srcdir/gcc/. -I../../srcdir/gcc/../include
-I../../srcdir/gcc/../libcpp/include  ../../srcdir/gcc/expr.c -o expr.o
Reading specs from /home/4/wilx/lib/gcc/i386-unknown-freebsd4.10/4.0.0/specs
Configured with: ../srcdir/configure --disable-nls
--enable-version-specific-runtime-libs --enable-dwarf2 --with-cpu=pentium3
--with-arch=pentium3 --with-system-zlib --disable-shared --prefix=/home/4/wilx
--enable-languages=c,c++,objc --disable-sjlj-exceptions
--enable-shared=libstdc++ --enable-shared=libobjc --with-gc=zone
Thread model: posix
gcc version 4.0.0 20041016 (experimental)
 /home/4/wilx/libexec/gcc/i386-unknown-freebsd4.10/4.0.0/cc1 -quiet -v
-I/home/4/wilx/include -I. -I. -I../../srcdir/gcc -I../../srcdir/gcc/.
-I../../srcdir/gcc/../include -I../../srcdir/gcc/../libcpp/include
-DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -DHAVE_CONFIG_H
../../srcdir/gcc/expr.c -quiet -dumpbase expr.c -march=pentium3 -auxbase-strip
expr.o -g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -version
-fno-common -o /var/tmp//ccbNklGP.s
ignoring nonexistent directory
"/home/4/wilx/lib/gcc/i386-unknown-freebsd4.10/4.0.0/../../../../i386-unknown-freebsd4.10/include"
ignoring duplicate directory "/home/4/wilx/include"
  as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "."
ignoring duplicate directory "../../srcdir/gcc/."
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../srcdir/gcc
 ../../srcdir/gcc/../include
 ../../srcdir/gcc/../libcpp/include
 /usr/local/include
 /home/4/wilx/include
 /home/4/wilx/lib/gcc/i386-unknown-freebsd4.10/4.0.0/include
 /usr/include
End of search list.
GNU C version 4.0.0 20041016 (experimental) (i386-unknown-freebsd4.10)
compiled by GNU C version 4.0.0 20041016 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -o expr.o /var/tmp//ccbNklGP.s

Now please observe GCC 2.8.1's behaviour. Notice the include paths ordering this
time too. Same environment just different bootstrap compiler.

[EMAIL PROTECTED]:::~/tmp/gcc-head/objdir/gcc> adagcc -v -c   -g -DENABLE_CHECKING
-DENABLE_ASSERT_CHECKING -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes  -fno-common -Wno-error  -DHAVE_CONFIG_H
-I/home/4/wilx/include   -I. -I. -I../../srcdir/gcc -I../../srcdir/gcc/.
-I../../srcdir/gcc/../include -I../../srcdir/gcc/../libcpp/include  c-parse.c -o
c-parse.o
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-freebsd4.10/2.8.1/specs
gcc version 2.8.1
 /usr/local/lib/gcc-lib/i386-unknown-freebsd4.10/2.8.1/cpp -lang-c -v
-I/home/4/wilx/include -I. -I. -I../../srcdir/gcc -I../../srcdir/gcc/.
-I../../srcdir/gcc/../include -I../../srcdir/gcc/../libcpp/include -undef
-D__GNUC__=2 -D__GNUC_MINOR__=8 -Di386 -Dunix -D__ELF__ -D__FreeBSD__=4
-D__i386__ -D__unix__ -D__ELF__ -D__FreeBSD__=4 -D__i386 -D__unix
-Asystem(FreeBSD) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -g -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wno-error -Di386
-Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) -Acpu(i386)
-Amachine(i386) -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H c-parse.c /tmp/cczdxxvj.i
GNU CPP version 2.8.1 (i386 FreeBSD/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /home/4/wilx/include
 .
 ../../srcdir/gcc
 ../../srcdir/gcc/../include
 ../../srcdir/gcc/../libcpp/include
 /usr/local/include
 /usr/local/i386-unknown-freebsd4.10/include
 /usr/local/lib/gcc-lib/i386-unknown-freebsd4.10/2.8.1/include
 /usr/include
End of search list.
In file included from ../../srcdir/gcc/../libcpp/include/cpplib.h:29,
 from c-parse.y:42:
/home/4/wilx/include/config.h:1: #error "config.h in ~/include!!!"

This time /home/4/wilx/include has made it to the first include path that is
searched. For better illustration I have changed the original ~/include/config.h
that has been installed by INN with my own one:

[EMAIL PROTECTED]:::~/tmp/gcc-head/objdir/gcc> cat ~/include/config.h
#error "config.h in ~/include!!!"

-- 
   Summary: Bootstrap with GCC 2.8.1 and CFLASG="-I${HOME}/include"
and config.h in ~/include is broken
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: 

[Bug bootstrap/18062] Bootstrap with GCC 2.8.1 and CFLASG="-I${HOME}/include" and config.h in ~/include is broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 16:57 
---
Not a bug, since /home/4/wilx is a prefix , /home/4/wilx/include is always included 
after the user 
includes even though you aupply it on the command line.  The bug was 2.8.x which 
cannot be changed 
and is so old nobody cares about it.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/18063] New: Gcc doesn't check overflowed size of structure

[mikulas at artax dot karlin dot mff dot cuni dot cz]

The following code compiles and runs, but shouldn't, because the size of
structure a overflows size_t type. Overflowed size is checked for arrays, for
global and local variables, but not for structures.

struct a {
char x[0x7fff];
char b[0x7fff];
char c[3];
};

main()
{
struct a *b = malloc(sizeof(struct a));
return sizeof (struct a);
}

-- 
   Summary: Gcc doesn't check overflowed size of structure
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
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=18063

gcc-bugs@gcc.gnu.org

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-19 17:24 
---
Subject: Bug 17885

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-19 17:24:48

Modified files:
gcc: ChangeLog tree.c 

Log message:
PR middle-end/17885
* tree.c (recompute_tree_invarant_for_addr_expr): Always poll address
of INDIRECT_REF.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5948&r2=2.5949
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.437&r2=1.438



-- 


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

[Bug c/18063] Gcc doesn't check overflowed size of structure

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 17:25 
---
On the mainline we warn:
t68.c:9: warning: integer overflow in expression

So maybe this can be considered fixed.

-- 


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

[Bug c++/17852] [4.0 Regression] weird quoting with synax error

[jsm at polyomino dot org dot uk]

--- Additional Comments From jsm at polyomino dot org dot uk  2004-10-19 17:28 
---
Subject: Re:  Re: [Bug c/18059] New: bad diagnostic formatting

On Tue, 19 Oct 2004, nathan at gcc dot gnu dot org wrote:

> c-common.c contains
>   void c_parse_error (const char *msgid, enum cpp_ttype token, tree value)
> 
> which purports to format msgid, however, it contains things like,
>error ("%s at end of input", string);
> thus any magic %< in MSGID do not get munged.  Resulting in,
>  error: expected %<,%> or %<...%> before '>' token
> 
> There needs to be a nesting mechanism to pass a format string as a % escape.

That the parameter is called msgid simply means it is translated - which 
it is.  There are at least three separate bugs here.

(1) The C++ front end shouldn't, for now, use these escapes in strings 
passed to c_parse_error.

(2) The message parameter to cp_parser_error is called "message" rather 
than "msgid", so the messages don't get in the message catalog.  Much the 
same applies to several other functions in the C++ parser: 
cp_parser_require, cp_parser_name_lookup_error, 
cp_parser_non_integral_constant_expression all take English arguments that 
aren't marked for translation and may not end up getting passed to _() in 
all cases.  cp_parser_require also concatenates the argument with the 
string "expected ".  The type_definition_forbidden_message structure 
member has a similar problem.

(3) c_parse_error combines a string (which may need %< and %>) with 
another part of a sentence with %s.  Combining sentence fragments cannot 
work with i18n, apart from the problems with message formatting.  The 
source code must contain all the full sentences output even though this 
bulks up the source by needing 8 different "expected .. before ..." in the 
error function call for every parser error: only that way can all the 
sentences be translated properly.  Making each call pass eight arguments 
rather than one is fortunately a fairly mechanical change, as the new 
arguments are derived from the existing one in a fixed way.



-- 


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

[Bug c/18063] Gcc doesn't check overflowed size of structure

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Additional Comments From mikulas at artax dot karlin dot mff dot cuni dot cz  
2004-10-19 17:32 ---
Subject: Re:  Gcc doesn't check overflowed size of structure

If you rewrite it to

int main(void)
{
size_t c = sizeof(struct a);
struct a *b = malloc(c);
return sizeof (struct a);
}

, it doesn't give warning with -W -Wall (except for unused b).

BTW. for array too large it gives error, so I think for structure, it
should too.

Mikulas


-- 


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

[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-19 18:03 
---
> Can you try it and see if it works for you?

Like a charm :-)  Thanks!


-- 


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

[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)

[davidm at hpl dot hp dot com]

--- Additional Comments From davidm at hpl dot hp dot com  2004-10-19 18:08 ---
(In reply to comment #2)
> Subject: Re:  New: bad unwind info due to multiple
>   returns (missing epilogue)
> On Fri, 2004-10-15 at 04:14, davidm at hpl dot hp dot com wrote:
> > To fix this bug, GCC should be emitting a ".restore sp" directive in front 
of
> > every instruction which pops the stack-pointer.
> I'm still sick, four weeks and counting, but this looks like a pretty
> easy one.  We just need to copy RTX_FRAME_RELATED_P when we copy
> instructions.  The following patch gives the right result for the
> testcase.  I have as yet done no other testing of the patch.

Thanks for coming up with a patch so quickly!  I'm currently on travel but 
I'll try running it against the C, C++, and Java test-suites once I'm back on 
Thursday.  It looks like things are getting very close to getting perfect 
unwind info.

Hope you get well soon!

  --david


-- 


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

[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 18:26 
---
Patch posted here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c/18063] Gcc doesn't check overflowed size of structure

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 18:30 
---
Note if you make a global variable of the struct we do error out.

-- 
   What|Removed |Added

   Keywords||diagnostic


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

[Bug fortran/13490] Compiler rejects valid constant -2147483648 for 32-bit int

[coyote at coyotegulch dot com]

--- Additional Comments From coyote at coyotegulch dot com  2004-10-19 18:49 
---
Posted a slightly revised patch, ten months after the first.

-- 


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

[Bug fortran/17912] gfortran: Bogus "Arithmetic overflow" error, regression w.r.t. g77

[coyote at coyotegulch dot com]

--- Additional Comments From coyote at coyotegulch dot com  2004-10-19 18:54 
---
I've posted an update to the original "asymmetric integers" patch, but it did
not address this specific PR.


-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-19 19:07 ---
In principle, requiring 2.15 and updating the docs seems ok: by the time 4.0.0
will be out, 2.15 (in its various incarnations) will we rather common. However,
I'm puzzled that nobody noticed this bug til now, I hope that somebody knows
better, maybe the bug affects only *some* versions of 2.14...

-- 


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

[Bug fortran/17912] gfortran: Bogus "Arithmetic overflow" error, regression w.r.t. g77

[coyote at coyotegulch dot com]

--- Additional Comments From coyote at coyotegulch dot com  2004-10-19 19:06 
---
Correction: My patch does fix this bug. See:

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01613.html

-- 


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

[Bug fortran/13490] Compiler rejects valid constant -2147483648 for 32-bit int

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 19:15 
---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/17962] [4.0 Regression] small fp vector uses sse/mmx vectors and is not aligned

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-19 19:15 
---
Subject: Bug 17962

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-19 19:15:32

Modified files:
gcc: ChangeLog stor-layout.c 

Log message:
PR 17962
* stor-layout.c (layout_type): Set TYPE_ALIGN for vectors.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5950&r2=2.5951
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gcc&r1=1.215&r2=1.216



-- 


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

[Bug target/17962] [4.0 Regression] small fp vector uses sse/mmx vectors and is not aligned

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-19 19:21 
---
Subject: Bug 17962

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-19 19:21:42

Added files:
gcc/testsuite/gcc.dg: align-2.c 

Log message:
Testcase for PR 17962.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/align-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug target/17962] [4.0 Regression] small fp vector uses sse/mmx vectors and is not aligned

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-10-19 19:22 ---
Fixed.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2004-10-19 19:25 
---
Yes, this fixes the problems.  Thanks!  Two-process fixincludes now builds.


-- 


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

[Bug c++/18064] New: gcc lets subclasses use noncovariant return types

[joshh at google dot com]

We've been developing an app under gcc-3.4, and
were pleased with how strictly gcc-3.4 enforced
the C++ standard :-)
But in porting to another compiler, we discovered
that gcc had let us use a nonportable construct:
Types like void*, int*, and float* are not covariant,
but gcc happily lets subclasses and superclasses
use them interchangably for return types.

The following example demonstrates the problem; it
compiles ok on gcc even with -W -Wall, but not on
ICC 8.1 or Comeau's online compiler:

typedef int type1;
typedef float type2;

class A {
  virtual ~A() {};
  virtual void * result() const = 0;
};

class B : public A {
  virtual type1 * result() const { return new type1; };
};

class C : public A {
  virtual type2 * result() const { return new type2; };
};


ICC 8.1 Errors:
Intel(R) C++ Compiler for 32-bit applications, Version 8.1Build 20040921Z
Package ID: l_cc_pc_8.1.022

test-covarient.cc(14): error: return type is not identical to nor covariant with
return type "void *" of overridden virtual function function "A::result"
virtual type1 * result() const { return new type1; };
^

test-covarient.cc(18): error: return type is not identical to nor covariant with
return type "void *" of overridden virtual function function "A::result"
virtual type2 * result() const { return new type2; };


Comeau Errors:
Comeau C/C++ 4.3.3 (Aug  6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing.  All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 10: error: return type is not identical to nor covariant with
  return type "void *" of overridden virtual function function
  "A::result"
virtual type1 * result() const { return new type1; };
^

"ComeauTest.c", line 14: error: return type is not identical to nor covariant with
  return type "void *" of overridden virtual function function
  "A::result"
virtual type2 * result() const { return new type2; };

-- 
   Summary: gcc lets subclasses use noncovariant return types
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joshh at google dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-unknown-linux-gnu
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug c++/18064] gcc lets subclasses use noncovariant return types

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 19:35 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
  Known to fail||3.4.0 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-10-19 19:35:34
   date||


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

[Bug tree-optimization/18046] Missed jump threading optimization

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-10-19 20:16 ---
Subject: Re:  Missed jump threading
optimization

On Mon, 2004-10-18 at 16:50, stevenb at suse dot de wrote:
> --- Additional Comments From stevenb at suse dot de  2004-10-18 22:50 ---
> Subject: Re:  Missed jump threading optimization
> 
> Hmm, threading the default case sounds interesting, but the real
> reason why the RTL threader catches this and the tree threader does
> not is because on RTL the test case basically looks like this:
> 
> extern void foo (void);
> extern int i;
> void
> bar (void)
> {
>   if (i == 0)
> foo ();
> 
>   if (i == 0)
> foo ();
> }
> 
> Hey, I can thread that!  :-)
> 
> So perhaps we should consider lowering SWITCH_EXPRs with only two
> targets to COND_EXPRs after all...?  That would be quite easy to
> do.
Jan and maybe others have talked about lowering SWITCH_EXPRs
earlier.  I don't recall if it ever got implemented.

jeff



-- 


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

[Bug c/18065] New: wrong built-in functions selected

[schlie at comcast dot net]

Overall, the major problem is that the lhs operand object type, or most
optimal compatible type in the case of immedite operands, is not being
used to correcly select builtin functions; which is fairly important for
a compiler for 8-bit target to get right; where (u)divmod(q/h)i4 signed and
unsigned 8 and 16 bit builtin verions of the / and % functions corespondingly.

(This bug is independant of bug #10733, which doesn't actually seem
as a bug to me, unless the divmod built-in functions are coded incorrectly,
implies the use of divmodhi4 16 bit signed builtin; just as t1% = 30 implies
the use of the udivmodqi4 unsigned 8-bit builtin.
per ref:  )

The following main.c and main.lss file listings demonstrate the failure:

// main.c
//
// inspecting code using avr-gcc 3.4.3 & buinutils 2.15.x as of 10/16/04 snapshots:

int main( void ){

volatile   signed char s;
volatile unsigned char u;

// 
// Overall, the major problem is that the lhs operand object type, or most
// optimal compatible type in the case of immedite operands, is not being
// used to correcly select builtin functions; which is fairly important for
// a compiler for 8-bit target to get right; where (u)divmod(q/h)i4 signed and
// unsigned 8 and 16 bit builtin verions of the / and % functions corespondingly.
// 
// (This bug is independant of bug #10733, which doesn't actually seem
// as a bug to me, unless the divmod built-in functions are coded incorrectly,
// as in t1 = (t1 + 40) % 30; the (t1 + 40) sub-exp returns an int, which then
// implies the use of divmodhi4 16 bit signed builtin; just as t1% = 30 implies
// the use of the udivmodqi4 unsigned 8-bit builtin. 
// per ref:  )

char ss = s % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
char su = s % u ; //<__divmodhi4> correct.
char us = u % s ; //<__divmodhi4> correct.
char uu = u % u ; //<__udivmodqi4> correct.

// although optminally selecting the builtin's for rhs immediate's:
char sn = s % -3 ; //<__divmodqi4> correct. 
char sp = s % +3 ; //<__divmodqi4> correct.
char un = u % -3 ; //<__divmodhi4> correct.
char up = u % +3 ; //<__udivmodqi4> correct.

// it never recognizes any opportunites for lhs immeidate's ?:

char ns = -3 % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
char ps = +3 % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
char nu = -3 % u ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
char pu = +3 % u ; //<__divmodhi4> wrong, should be 8-bit unsigned <__udivmodqi4>

// but does optimally select based on expicitly cast immediate values:

char uc = u % ( char)-3 ; //<__udivmodqi4> correct, :: unsigned char
char ux = u % (  signed char)-3 ; //<__divmodhi4> correct.
char uy = u % (unsigned char)-3 ; //<__udivmodqi4> correct.
char cu = ( char)-3 % u ; //<__udivmodqi4> correct, :: unsigned char
char xu = (  signed char)-3 % u ; //<__divmodhi4> correct.
char yu = (unsigned char)-3 % u ; //<__udivmodqi4> correct.
char sc = s % ( char)-3 ; //<__divmodhi4> correct, :: unsigned char
char sx = s % (  signed char)-3 ; //<__divmodqi4> correct.
char sy = s % (unsigned char)-3 ; //<__divmodhi4> correct.
char cs = ( char)-3 % s ; //<__divmodhi4> correct, :: unsigned char
char xs = (  signed char)-3 % s ; //<__divmodhi4> wrong, should be 8-bit 
<__divmodqi4>
char ys = (unsigned char)-3 % s ; //<__divmodhi4> correct.

return ss + su + us + uu +
   sn + sp + un + up +
   ns + ps + nu + pu +
   uc + ux + uy + cu + xu + yu +
   sc + sx + sy + cs + xs + ys ;
}

/*
main.lss file listing:

--begin--

main.elf: file format elf32-avr

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .data   00800100  034e  03e2  2**0
  CONTENTS, ALLOC, LOAD, DATA
  1 .text 034e      0094  2**0
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .bss    00800100  034e  03e2  2**0
  ALLOC
  3 .noinit     00800100  00800100  03e2  2**0
  CONTENTS
  4 .eeprom     0081  0081  03e2  2**0
  CONTENTS
  5 .stab 0600      03e4  2**2
  CONTENTS, READONLY, DEBUGGING
  6 .stabstr  04c6      09e4  2**0
  CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:

 <__vectors>:
   0:   0c 94 46 00 jmp 0x8c
   4:   0c 94 61 00 jmp 0xc2
   8:   0c 94 61 00 jmp 0xc2
   c:   0c 94 61 00 jmp 0xc2
  10:   0c 94 61 00 jmp 0xc2
  14:   0c 94 61 00 jmp 0xc2
  18:   0c 94 61 00 jmp 

[Bug c/18065] wrong built-in functions selected

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-19 20:27 ---
Created an attachment (id=7378)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7378&action=view)
main.c (with embedded commented out main.lss and makefile)


-- 


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-19 20:31 
---
At least 2.14 is not uncommon, SuSE 9.0 is affected for example.
So there are lots of people out there who will run into trouble. :-(


-- 


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

[Bug target/18065] wrong built-in functions selected

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 20:39 
---
char ss = s % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
This is not wrong as we sign extend the arguments as required by the C standard (to 
int).

So this is just an missed-optimization.

-- 
   What|Removed |Added

   Severity|critical|minor
  Component|c   |target
   Keywords||missed-optimization


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

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

[veksler at il dot ibm dot com]

--- Additional Comments From veksler at il dot ibm dot com  2004-10-19 20:53 
---
Subject: Re:  Undefined reference to ~basic_iostream(),  with -O[12]


I also think that 2.14 is not uncommon. RHEL-3 is also affected.
If this is fixed, I'll continue my efforts to evaluate gcc-4.0 (and report
more bugs -
there seems to be an unrelated bad code bug that I cannot analyze before
this PR
gets fixed).

By the way, libstdc++.a looks OK. This means that "g++ -static" works fine
(verified on my tO3.cpp example, and on the streambuf example referenced in
comment 2)



-- 


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

[Bug tree-optimization/17841] table lookups vs binary search in switch-statements

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 20:59 
---
Fixed on the mainline, the resulting code for the two functions are the same now.

-- 
   What|Removed |Added

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


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

[Bug target/18065] wrong built-in functions selected

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-19 21:18 ---
Subject: Re:  wrong built-in functions selected

Nope, please look at the coded examples:

- they demonstrate that:

  (signed char) % (signed char) => invokes (int) % (int), not correct.

- and the compiler consistently treats rhs immediate value differently
  than lhs immediate values for some non-descript reason? (arguably,
  it should assume all immediate values are ints unless cast/specified
  otherwise, but that's not what it does, nor does it properly treat
  lhs operands as signed chars even if properly explicitly cast.

Thanks, -paul-

> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 19 Oct 2004 20:39:44 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug target/18065] wrong built-in functions selected
> 
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19
> 20:39 ---
> char ss = s % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
> This is not wrong as we sign extend the arguments as required by the C
> standard (to int).
> 
> So this is just an missed-optimization.
> 
> -- 
>What|Removed |Added
> 
>Severity|critical|minor
>   Component|c   |target
>Keywords||missed-optimization
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.




-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[jgrimm2 at us dot ibm dot com]

--- Additional Comments From jgrimm2 at us dot ibm dot com  2004-10-19 21:25 
---
I see this too.  Or rather, I see what Michael is describing. Should there be a
new bug for the problem as described by Michael?  My test scenario was from
desire to build 64-bit biarch compiler that defaults to m64.  The system
compiler was 32-bit biarch compiler that defaults to m32.   


Here's how I had configured: 
/home/jgrimm/gcc_priv_mline_anoncvs/gcc/configure
--prefix=/home/jgrimm/tools/gcc-work --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default64
--with-as=/home/jgrimm/tools/binutils/bin/as
--with-ld=/home/jgrimm/tools/binutils/bin/ld --enable-threads=\posix
--enable-shared --enable-__cxa_atexit --enable-languages=c --enable-biarch

Error output:
...
stage1/xgcc -Bstage1/ -B/home/jgrimm/tools/gcc-work/powerpc64-linux/bin/   -g
-O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
 -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genmodes \
 build/genmodes.o build/errors.o ../build-powerpc64-linux/libiberty/libiberty.a
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(hashtab.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(xmalloc.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(xstrdup.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(xexit.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: can not size stub section: Bad value


-- 


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

[Bug target/18065] wrong built-in functions selected

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-19 21:31 ---
Subject: Re:  wrong built-in functions selected

As of course otherwise then, what's the purpose of s/u 8-bit / and  %
built-in functions, if not to enable their use when all the operands are
type compatible, minimally explicitly and ideally when type compatible?

-paul-

> From: schlie at comcast dot net <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 19 Oct 2004 21:18:17 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug target/18065] wrong built-in functions selected
> 
> 
> --- Additional Comments From schlie at comcast dot net  2004-10-19 21:18
> ---
> Subject: Re:  wrong built-in functions selected
> 
> Nope, please look at the coded examples:
> 
> - they demonstrate that:
> 
>   (signed char) % (signed char) => invokes (int) % (int), not correct.
> 
> - and the compiler consistently treats rhs immediate value differently
>   than lhs immediate values for some non-descript reason? (arguably,
>   it should assume all immediate values are ints unless cast/specified
>   otherwise, but that's not what it does, nor does it properly treat
>   lhs operands as signed chars even if properly explicitly cast.
> 
> Thanks, -paul-
> 
>> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
>> Reply-To: <[EMAIL PROTECTED]>
>> Date: 19 Oct 2004 20:39:44 -
>> To: <[EMAIL PROTECTED]>
>> Subject: [Bug target/18065] wrong built-in functions selected
>> 
>> 
>> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19
>> 20:39 ---
>> char ss = s % s ; //<__divmodhi4> wrong, should be 8-bit <__divmodqi4>
>> This is not wrong as we sign extend the arguments as required by the C
>> standard (to int).
>> 
>> So this is just an missed-optimization.
>> 
>> -- 
>>What|Removed |Added
>> 
>>Severity|critical|minor
>>   Component|c   |target
>>Keywords||missed-optimization
>> 
>> 
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
>> 
>> --- You are receiving this mail because: ---
>> You reported the bug, or are watching the reporter.
> 
> 
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.




-- 


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

[Bug ada/18066] New: GCC error: in expand_call, at calls.c

[timothy dot a dot runkle at nasa dot gov]

Hello,
I recently installed Fedora Core 2 (everything), downloaded and attempted to
build GtkAda-2.2.1. The build fails during compilation of one of the ada files.
Here's the snippet of text from near the occurrence of error:


gcc -c -I../ -O2 -gnatn -gnatws -fPIC -I- ../gtk-viewport.adb
gcc -c -I../ -O2 -gnatn -gnatws -fPIC -I- ../gtk-widget.adb
gcc -c -I../ -O2 -gnatn -gnatws -fPIC -I- ../gtk-window.adb
gcc -c -I../ -O2 -gnatn -gnatws -fPIC -I- ../gtkada.ads
gcc -c -I../ -O2 -gnatn -gnatws -fPIC -I- ../gtkada-canvas.adb
+===GNAT BUG DETECTED==+
| 3.3.3 20040412 (Red Hat Linux 3.3.3-7) (i386-redhat-linux-gnu) GCC error:|
| in expand_call, at calls.c:3112  |
| Error detected at ../gtkada-canvas.adb:1205:13   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| concatenated together with no headers between files. |
+==+

Please include these source files with error report
 
../gtkada-canvas.adb
../gtkada-canvas.ads
../gtkada.ads
../gdk.ads

 - lots of files -

../glib-type_conversion_hooks.ads
../gtk-object.adb
 
compilation abandoned
gnatmake: "../gtkada-canvas.adb" compilation error
make[1]: *** [lib-obj/make_gtk.o] Error 4
make[1]: Leaving directory `/home/trunkle/GtkAda/GtkAda/src'
make: *** [install] Error 2


And the compiler version I'm using.

% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

I found a similar bug in the frequent bug list. However not exactly my problem.
Please let me know if you need files/additional data. I'm pretty new to building
compilers. If there's something additional I need to do please advise.

-- 
   Summary: GCC error: in expand_call, at calls.c
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timothy dot a dot runkle at nasa dot gov
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: 3.3.3
  GCC host triplet: 3.3.3
GCC target triplet: 3.3.3


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

[Bug target/18065] not using qi version of divmod

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 21:39 
---
I don't know but as I said this is correct code and not a wrong code problem but just 
a missed 
optimization somewhere.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|powerpc-apple-darwin7.5.0   |
   GCC host triplet|powerpc-apple-darwin7.5.0   |
   Last reconfirmed|-00-00 00:00:00 |2004-10-19 21:39:26
   date||
Summary|wrong built-in functions|not using qi version of
   |selected|divmod


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

[Bug ada/18066] GCC error: in expand_call, at calls.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 21:41 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug ada/13016] [Ada] GNAT bug box: in expand_call, at calls.c:3098

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 21:41 
---
*** Bug 18066 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||timothy dot a dot runkle at
   ||nasa dot gov


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

[Bug target/18065] not using qi version of divmod

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-19 21:53 ---
Subject: Re:  not using qi version of divmod

I agree that the missed optimizations won't produce incorrect results, just
very inefficient ones. As all rhs argument optimizations seem to be properly
identified, and yet no lhs's are; it would imply to me that where ever in
gcc argument signatures are being computed or used for the purpose of
built-in function selection, it's inappropriately ignoring lhs argument
type compatibility; would you agree with that somewhat crude assessment?

Thanks again,-paul-

> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 19 Oct 2004 21:39:27 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug target/18065] not using qi version of divmod
> 
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19
> 21:39 ---
> I don't know but as I said this is correct code and not a wrong code problem
> but just a missed
> optimization somewhere.
> 
> -- 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>  Ever Confirmed||1
>   GCC build triplet|powerpc-apple-darwin7.5.0   |
>GCC host triplet|powerpc-apple-darwin7.5.0   |
>Last reconfirmed|-00-00 00:00:00 |2004-10-19 21:39:26
>date||
> Summary|wrong built-in functions|not using qi version of
>|selected|divmod
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.




-- 


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

[Bug target/18065] not using qi version of divmod

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2004-10-19 22:08 ---
Bug #10733 is related.

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug target/18065] not using qi version of divmod

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2004-10-19 22:31 ---
Subject: Re:  not using qi version of divmod

Hi Eric,

Out of curiosity, what exactly is the 10733 bug, is wrong result computed?

If so, that implies that divmodhi is broken; otherwise it's not a bug, as
the intermediate (t1 + 40) expression yields an int result, as within the
context of the expression, although t1 is an unsigned char, there's no
guarantee that (t1 + 40) will not overflow an unsigned char size, therefore
properly assumed to be an int; unlike t1 = t1 % 3 or whatever, where all
operands are clearly type compatible with unsigned char, and a valid
optimization.

-paul-

> From: ericw at evcohs dot com <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: 19 Oct 2004 22:08:15 -
> To: <[EMAIL PROTECTED]>
> Subject: [Bug target/18065] not using qi version of divmod
> 
> 
> --- Additional Comments From ericw at evcohs dot com  2004-10-19 22:08
> ---
> Bug #10733 is related.
> 
> -- 
>What|Removed |Added
> 
>  CC||ericw at evcohs dot com
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.




-- 


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

[Bug debug/18067] New: ICE at loc_descriptor_from_tree_1 in dwarf2out.c

[phython at gcc dot gnu dot org]

While compiling snow.c from ffmpeg loc_descriptor_from_tree_1 segfaults.

Here is the stack trace:
#0  fancy_abort (file=0x1048ec30 "/home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c",
line=9190, function=0x105e5e98 "loc_descriptor_from_tree_1")
at /home/jim/cvs/gcc.head/gcc/gcc/diagnostic.c:556
#1  0x1018ff14 in loc_descriptor_from_tree_1 (loc=0xa, want_address=0)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:9190
#2  0x1018f964 in loc_descriptor_from_tree_1 (loc=0x304fd988, want_address=0)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:9099
#3  0x1018f964 in loc_descriptor_from_tree_1 (loc=0x304fd9b0, want_address=2)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:9099
#4  0x10197168 in add_bound_info (subrange_die=0x3063bb70,
bound_attr=DW_AT_upper_bound, bound=0x304fd9b0)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:9223
#5  0x1019b0dc in gen_array_type_die (type=0x304ff000, context_die=0x3063b120)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:10271
#6  0x10195394 in gen_type_die (type=0x304ff000, context_die=0x3063b120)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:12101
#7  0x10193b90 in gen_decl_die (decl=0x304ff100, context_die=0x3063b120)
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:12643
#8  0x10199ff4 in decls_for_scope (stmt=0x3050c690, context_die=0x3063b120,
depth=0) at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:12330
#9  0x10198288 in gen_subprogram_die (decl=0x304f9200, context_die=Variable
"context_die" is not available.
at /home/jim/cvs/gcc.head/gcc/gcc/dwarf2out.c:11400
#10 0x1037b9bc in rest_of_compilation ()
at /home/jim/cvs/gcc.head/gcc/gcc/passes.c:340
#11 0x10089694 in execute_pass_list (pass=0x105ec0c8)
at /home/jim/cvs/gcc.head/gcc/gcc/tree-optimize.c:503
#12 0x100899f8 in tree_rest_of_compilation (fndecl=0x304f9200)
at /home/jim/cvs/gcc.head/gcc/gcc/tree-optimize.c:635
#13 0x1001a9c0 in c_expand_body (fndecl=0x304f9200)
at /home/jim/cvs/gcc.head/gcc/gcc/c-decl.c:6371
#14 0x103ab764 in cgraph_expand_function (node=0x30517100)
at /home/jim/cvs/gcc.head/gcc/gcc/cgraphunit.c:1045
#15 0x103afe90 in cgraph_optimize ()
at /home/jim/cvs/gcc.head/gcc/gcc/cgraphunit.c:2726
#16 0x1001d2c8 in c_write_global_declarations ()
at /home/jim/cvs/gcc.head/gcc/gcc/c-decl.c:7349
#17 0x1034b4fc in toplev_main (argc=Variable "argc" is not available.
)
at /home/jim/cvs/gcc.head/gcc/gcc/toplev.c:999
#18 0x1006710c in main (argc=Variable "argc" is not available.
) at /home/jim/cvs/gcc.head/gcc/gcc/main.c:35

-- 
   Summary: ICE at loc_descriptor_from_tree_1 in dwarf2out.c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
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
 GCC build triplet: ppc-linux
  GCC host triplet: ppc-linux
GCC target triplet: ppc-linux


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

[Bug debug/18067] ICE at loc_descriptor_from_tree_1 in dwarf2out.c

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2004-10-19 23:05 
---
Created an attachment (id=7379)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7379&action=view)
preprocessed source for snow.c

 Compile with -O1 -g

-- 


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

[Bug debug/18067] ICE at loc_descriptor_from_tree_1 in dwarf2out.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 23:12 
---
Might be related to PR 14900 or 17076 but I cannot reproduce this on powerpc-darwin 
(even after 
supplying -gdwarf-2 since dwarf-2 is not default).

-- 


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

[Bug target/18065] not using qi version of divmod

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2004-10-19 23:13 ---
Subject: Re:  not using qi version of divmod

schlie at comcast dot net wrote:

>--- Additional Comments From schlie at comcast dot net  2004-10-19 22:31 ---
>Subject: Re:  not using qi version of divmod
>
>Hi Eric,
>
>Out of curiosity, what exactly is the 10733 bug, is wrong result computed?
>
>If so, that implies that divmodhi is broken; otherwise it's not a bug, as
>the intermediate (t1 + 40) expression yields an int result, as within the
>context of the expression, although t1 is an unsigned char, there's no
>guarantee that (t1 + 40) will not overflow an unsigned char size, therefore
>properly assumed to be an int; unlike t1 = t1 % 3 or whatever, where all
>operands are clearly type compatible with unsigned char, and a valid
>optimization.
>  
>
Bug #10733 is a wrong-code bug involving the modulus operator on the AVR 
target. See the bug report itself for more information.
Eric


-- 


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

[Bug debug/18067] ICE at loc_descriptor_from_tree_1 in dwarf2out.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 23:14 
---
I can produce with a cross to i686-pc-linux, reducing.

-- 


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

[Bug c++/14035] [3.3/3.4/4.0 Regression] Compiler generates spurious temporary

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-10-19 23:30 
---
Fixed in GCC 4.0.

Will not be fixed in GCC 3.4.x.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/14035] [3.3/3.4/4.0 Regression] Compiler generates spurious temporary

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.3   |4.0.0


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

[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 23:43 
---
Here is the reduced testcase:
typedef unsigned int size_t;
extern void *memcpy (void *__restrict __dest,
   __const void *__restrict __src, size_t __n) ;

int encode_q_branch(int level, unsigned char *t, int stride1)
 {
const int block_w= level;
const int stride= stride1;
unsigned char current_mb[3][stride*block_w];
memcpy(¤t_mb[0][0], t, 1);
}


: Search converges between 2004-07-02-trunk (#477) and 2004-07-04-trunk (#478).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|debug   |tree-optimization
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2004-10-19 23:43:07
   date||
Summary|ICE at  |[4.0 Regression] ICE at
   |loc_descriptor_from_tree_1  |loc_descriptor_from_tree_1
   |in dwarf2out.c  |in dwarf2out.c (VLA)
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 23:49 
---
Oh, I forgot to say the problem is that we are not taking the variables in the size 
out of SSA form for 
some reason.
Here is the tree level at .vars which shows the problem:
  saved_stack.3 = __builtin_stack_save ();
  D.1135 = __builtin_alloca ((unsigned int) (level * stride1) * 3);
  memcpy ((unsigned char *) (unsigned char[(unsigned int) (block_w_3 * stride_5 - 1)] 
*) (unsigned 
char[2][(unsigned int) (block_w_3 * stride_5 - 1)] *) D.1135, t, 1);
  __builtin_stack_restore (saved_stack.3);

Note the block_w_3 and stride_5.

-- 


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

[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA)

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-20 00:01 
---
Here's an even shorter example (for i686-pc-linux-gnu):

=
void foo(int i)
{
const int j=i+1;
int a[1][j*j];
}
=

The regression seems to appear a little later with this example:
: Search converges between 2004-07-16-trunk (#487) and 2004-07-17-trunk (#488).

-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
   Keywords||monitored


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