[Bug objc/18971] [4.0 Regression] Can't send messages to methods with arrays as parameters

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-30 
10:18 ---
Subject: Bug 18971

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-30 10:18:18

Modified files:
gcc/objc   : ChangeLog objc-act.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/objc.dg: encode-5.m 

Log message:
[gcc/objc/ChangeLog]
2004-12-30  Ziemowit Laski  <[EMAIL PROTECTED]>

PR objc/18971
* objc-act.c (get_arg_type_list, start_method_def): Decay
array arguments into pointers.
(gen_type_name_0): Learn to pretty-print array types.

[gcc/testsuite/ChangeLog]
2004-12-30  Alexander Malmberg  <[EMAIL PROTECTED]>
Ziemowit Laski  <[EMAIL PROTECTED]>

PR objc/18971
* objc.dg/encode-5.m: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/ChangeLog.diff?cvsroot=gcc&r1=1.21&r2=1.22
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.258&r2=1.259
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4828&r2=1.4829
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/objc.dg/encode-5.m.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-12-30 
10:39 ---
Nope, my patch is not sufficient.  I am testing a better fix, but I fear it is
too invasive for 4.0.  It is a variant of the often-proposed "build out of
srcdir without telling the user" trick.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords|patch   |
 Resolution|FIXED   |


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

[Bug c++/19199] New: Wrong warning about returning a reference to a temporary

[lars at trolltech dot com]

Hi, 
 
The code below produces a warning about returning a reference to a temporary 
when using enum types for the qMin method. It works fine when using primitive 
types or classes instead of enums. 
 
Fortunately it's rather easy to work around the warning :) 
 
Best regards, 
Lars 
 
 
enum Foo { A, B }; 
 
template const T &qMin(const T &a, const T &b)  
{ return a < b ? a : b; } 
 
int main(int,  char **) 
{ 
Foo f = A; 
Foo g = B; 
Foo h = qMin(f, g); 
return 0; 
}

-- 
   Summary: Wrong warning about returning a reference to a temporary
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lars at trolltech dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/19128] Bug box while building asharp

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-30 
11:24 ---
Subject: Bug 19128

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-30 11:24:08

Modified files:
gcc/ada: ChangeLog trans.c 

Log message:
2004-12-30  Sohail Somani <[EMAIL PROTECTED]>

PR ada/19128
* trans.c (gnat_to_gnu): Fix typo: Use correct return variable.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.619&r2=1.620
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/trans.c.diff?cvsroot=gcc&r1=1.87&r2=1.88



-- 


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

[Bug c++/19200] New: Friend declaration misinterpreted as constructor

[giovannibajo at libero dot it]

Hello:

---
struct S {
   struct T{};
   friend void S(T);
};
---
lookup.cc:3: error: return type specification for constructor invalid
lookup.cc:3: warning: member functions are implicitly friends of their class


G++ thinks that the friend declaration is declaring the constructor (with an 
invalid return type specification) as friend. This is bogus of course.

It might be a regression, but it was there at least in 3.3.

-- 
   Summary: Friend declaration misinterpreted as constructor
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19200] Friend declaration misinterpreted as constructor

[giovannibajo at libero dot it]

-- 
   What|Removed |Added

  Known to fail||4.0.0 3.4.2 3.3.3


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

[Bug c++/18604] [3.4/4.0 Regression] Strong using lookup conflicts

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-30 
11:59 ---
This affects Boost, I'm bumping the priority.

-- 
   What|Removed |Added

   Priority|P2  |P1


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

[Bug target/19201] New: [m68k] Inefficient code for array accesses (from old PROBLEMS)

[steven at gcc dot gnu dot org]

Item 10 from the old PROBLEMS file (no test case available):


movl a3@,a0
movl a3@(16),a1
clrb a0@(a1:l)

is generated and may be worse than

movl a3@,a0
addl a3@(16),a0
clrb a0@

If ordering of operands is improved, many more such cases will be
generated from typical array accesses.


-- 
   Summary: [m68k] Inefficient code for array accesses  (from old
PROBLEMS)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19202] New: [cc0] Potential problem with cc_status.value2 (from old PROBLEMS)

[steven at gcc dot gnu dot org]

Item 63 from the old PROBLEMS file (no test case available):


Potential problem in cc_status.value2, if it
ever activates itself after a two-address subtraction (which currently
cannot happen).  It is supposed to compare the current value of the
destination but eliminating it would use the results of the
subtraction, equivalent to comparing the previous value of the
destination.


-- 
   Summary: [cc0] Potential problem with cc_status.value2 (from old
PROBLEMS)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19203] New: Partial ordering failure between function reference and generic const reference

[giovannibajo at libero dot it]

Hello:



template 
void foo(const A& a);

template 
void foo(RET (&)(ARG1));


float decl(int);

void bar(void)
{
  foo(decl);
}

lambda.cc:12: error: call of overloaded 'foo(float (&)(int))' is ambiguous
lambda.cc:2: note: candidates are: void foo(const A&) [with A = float ()(int)]
lambda.cc:5: note: void foo(RET (&)(ARG1)) [with RET = float, 
ARG1 = int]


I'm pretty sure that the latter overload is more specialized than the former, 
and EDG agress with me. Not sure if it is a regression.

-- 
   Summary: Partial ordering failure between function reference and
generic const reference
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: gcc-bugs at gcc dot gnu dot org,nathan at gcc dot gnu
dot org


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

[Bug c++/19203] Partial ordering failure between function reference and generic const reference

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-30 
12:19 ---
Bumping priority because it affects Boost.

-- 
   What|Removed |Added

   Priority|P2  |P1


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

[Bug target/19204] New: [m68k] pea can force reloads that cause inefficient code

[steven at gcc dot gnu dot org]

Item 85 from the old PROBLEMS file (no test case available):


pea can force a value to be reloaded into an areg which
can make it worse than separate adding and pushing.  This can only
happen for adding something within addql range and it only loses if
the qty becomes dead at that point so it can be added to with no
copying.


-- 
   Summary: [m68k] pea can force reloads that cause inefficient code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19203] Partial ordering failure between function reference and generic const reference

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-30 
12:20 ---
This is the Boost test which is failing because of this bug:
http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#function-
lambda_test-gcc-4-experimental-linux

-- 


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

[Bug target/19205] New: [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

[steven at gcc dot gnu dot org]

Item 109 from the old PROBLEMS file (no test case available):


It is desirable to avoid converting INDEX to SImode if a narrower
mode suffices, as HImode does on the 68000.  How can this be done?


-- 
   Summary: [m68k] avoid converting INDEX to SI mode if a narrower
mode suffices
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19206] New: [cc0] insn-output.c should optimize sign-tests better

[steven at gcc dot gnu dot org]

Item 122 from the old PROBLEMS file (no test case available):


When insn-output.c turns a bit-test into a sign-test, it should
see whether the condition code is already set up with that sign.


-- 
   Summary: [cc0] insn-output.c should optimize sign-tests better
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19207] New: Suggestion for speeding up data flow analysis

[steven at gcc dot gnu dot org]

This is a suggestion from item 108 of the "old PROBLEMS" file that
actually still makes a lot of sense, for a change:


Can speed up flow analysis by making a table saying
which register is set and which registers are used by each instruction
that only sets one register and only uses two.  This way avoid the
tree walk for such instructions (most instructions).


As it is now, we actually have this - sometimes.  The above is how we
compute liveness in df.c, and indeed it would be nice to unify these
parts of flow.c and df.c that are basically duplicating code. Liveness
is computed quite a few times in the RTL path, so speeding it up is a
Good Thing.

-- 
   Summary: Suggestion for speeding up data flow analysis
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-30 
13:16 ---
Subject: Bug 18019

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-30 13:16:14

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.md 

Log message:
PR target/18019
* i386.md (movqi_1): Fix -Os instruction choice.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6985&r2=2.6986
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.594&r2=1.595



-- 


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

[Bug c++/19208] New: [4.0 Regression] Spurious error about variably modified type

[giovannibajo at libero dot it]

Hello,

the code I will attacch shortly is a (partial) reduction from a multi-thousands 
line testcase from Boost which fails with 4.0.

This is the link to the failure in the automatic testers:
http://ln-s.net/2$N

-- 
   Summary: [4.0 Regression] Spurious error about variably modified
type
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19208] [4.0 Regression] Spurious error about variably modified type

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-30 
13:19 ---
Created an attachment (id=7845)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7845&action=view)
Reduced testcase (but not minimal)


-- 


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

[Bug c++/19208] [4.0 Regression] Spurious error about variably modified type

[giovannibajo at libero dot it]

-- 
   What|Removed |Added

   Severity|normal  |critical
   Priority|P2  |P1
   Target Milestone|--- |4.0.0


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

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-30 
13:21 ---
.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/19208] [4.0 Regression] Spurious error about variably modified type

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-30 
13:22 ---
A regression from what?  Does 3.4 accept it?


-- 


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

[Bug c++/19208] [3.4/4.0 Regression] Spurious error about variably modified type

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-30 
13:51 ---
3.4 is broken too, it's a regression from 3.3 actually.

-- 
   What|Removed |Added

  Known to fail||4.0.0 3.4.3
  Known to work||3.3.3
Summary|[4.0 Regression] Spurious   |[3.4/4.0 Regression]
   |error about variably|Spurious error about
   |modified type   |variably modified type
   Target Milestone|4.0.0   |3.4.4


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

[Bug tree-optimization/14705] [tree-ssa] more alias analysis needed!?

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-30 
14:05 ---
Looks like food for DannyB.

-- 
   What|Removed |Added

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


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

[Bug c++/19208] [3.4/4.0 Regression] Spurious error about variably modified type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
14:27 ---
Reduced testcase:
template  struct if_t { typedef int type; };
template  struct  { static const bool value = true; };
template 
struct bound_member_action
{
  typedef char f[::value ? 1 : 2];
  template 
  bound_member_action(CT i, typename if_t::type g)  {}
};
bound_member_action a(0, 1);



: Search converges between 2004-01-27-trunk (#442) and 2004-01-28-trunk (#443).

Just a note that date is when it started to seg fault.
We started to reject this (and not an ICE):
: Search converges between 2004-03-01-3.4 (#2) and 2004-03-15-3.4 (#3).
: Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447).


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 14:27:10
   date||


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

[Bug c++/19203] [3.4/4.0 Regression] Partial ordering failure between function reference and generic const reference

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
14:29 ---
: Search converges between 2004-04-01-trunk (#447) and 2004-04-10-trunk (#448).
: Search converges between 2004-06-15-3.4 (#9) and 2004-06-27-3.4 (#10).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.4.3 4.0.0
  Known to work||3.3.2 3.4.0
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 14:29:33
   date||
Summary|Partial ordering failure|[3.4/4.0 Regression] Partial
   |between function reference  |ordering failure between
   |and generic const reference |function reference and
   ||generic const reference
   Target Milestone|--- |3.4.4


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

[Bug ada/19128] Bug box while building asharp

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug c++/19200] Friend declaration misinterpreted as constructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
14:33 ---
If this is a regression, it has to be from 2.95.3 which I don't have access to 
right now.

Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail|4.0.0 3.4.2 3.3.3   |4.0.0 3.4.2 3.3.3 3.0 2.97
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 14:33:16
   date||


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

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
14:48 ---
Confirmed:
< = (const Foo &) (const Foo *) &TARGET_EXPR 
>>>
why is there a cast to int in the MIN_EXPR.

This causes wrong code.

-- 
   What|Removed |Added

   Severity|minor   |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic, wrong-code
  Known to fail||3.4.0 4.0.0 3.3.2
  Known to work||3.1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 14:48:58
   date||
Summary|Wrong warning about |[3.3/3.4/4.0 Regression]
   |returning a reference to a  |Wrong warning about
   |temporary   |returning a reference to a
   ||temporary
   Target Milestone|--- |3.4.4


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

[Bug objc/18971] [4.0 Regression] Can't send messages to methods with arrays as parameters

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
14:51 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/19207] Suggestion for speeding up data flow analysis

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 14:53:05
   date||


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

[Bug libstdc++/19209] New: libstdc++ tempers with user name space

[gdr at gcc dot gnu dot org]

Some uglifications are missing from current implementations
of the standard library

How to repeat:

% cat l.C && g++ l.C   
#define hook 1
#define unhook 0

#include 

int main()
{
   return 0;
}

/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:90:
error: expected unqualified-id before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:93:
error: expected unqualified-id before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:
In member function 'void std::list<_Tp,
_Alloc>::_M_insert(std::_List_iterator<_Tp>, const _Tp&)':
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:1150:
error: expected unqualified-id before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:1150:
error: expected `;' before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:
In member function 'void std::list<_Tp,
_Alloc>::_M_erase(std::_List_iterator<_Tp>)':
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:1157:
error: expected unqualified-id before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_list.h:1157:
error: expected `;' before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/list.tcc:
In member function 'typename std::list<_Tp, _Alloc>::iterator std::list<_Tp,
_Alloc>::insert(std::_List_iterator<_Tp>, const _Tp&)':
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/list.tcc:88:
error: expected unqualified-id before numeric constant
/home/gdr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/list.tcc:88:
error: expected `;' before numeric constant

-- 
   Summary: libstdc++ tempers with user name space
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: plateform independent


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

[Bug libstdc++/19209] [4.0 Regression] libstdc++ tempers with user name space

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
15:01 ---
Confirmed, this is at least a 4.0 regression, 3.3.2 compiled  this just fine.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0
  Known to work||3.3.2
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 15:01:10
   date||
Summary|libstdc++ tempers with user |[4.0 Regression] libstdc++
   |name space  |tempers with user name space
   Target Milestone|--- |4.0.0


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

[Bug libstdc++/19209] [3.4/4.0 Regression] libstdc++ tempers with user name space

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
15:08 ---
Hmm, the problem is in _List_node_base.
It was caused by:
2004-01-07  Gawain Bolton  <[EMAIL PROTECTED]>

* include/bits/stl_list.h:
* include/bits/list.tc:
* src/list.cc:
Performance enhancements for destructor, push_front(),
push_back(), pop_front(), pop_back(), sort()
Eliminated static_casts where possible.
Moved code out of header files into new src/list.cc
implementation file for library where possible.
Remove inheritance from iterator class and create separate
classes for non-constant and constant iterators.


Meaning that this is also a 3.4 regression.

-- 
   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org
  Known to fail|4.0.0   |4.0.0 3.4.0
Summary|[4.0 Regression] libstdc++  |[3.4/4.0 Regression]
   |tempers with user name space|libstdc++ tempers with user
   ||name space


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

[Bug libstdc++/19209] [3.4/4.0 Regression] libstdc++ tempers with user name space

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |3.4.4


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

[Bug libstdc++/19209] [3.4/4.0 Regression] libstdc++ tempers with user name space

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-30 15:16 
---
Already fixed in the v7 branch, by the way.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/16896] Use of non-reserved names in stl_list.h

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-30 15:16 
---
*** Bug 19209 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||gdr at gcc dot gnu dot org


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

[Bug rtl-optimization/19198] ICE in copyprop_hardreg_forward_1

[matt at gsicomp dot on dot ca]

--- Additional Comments From matt at gsicomp dot on dot ca  2004-12-30 
15:28 ---
Ignore the "gcc -v" that claims to be 2.95.4.  That's from the wrong gcc.

Here's the right info:

[EMAIL PROTECTED] gcc34 -v
Reading specs from /usr/local/lib/gcc/i386-portbld-freebsd4.10/3.4.4/specs
Configured with: ./..//gcc-3.4-20041210/configure --disable-nls --with-system-
zlib --with-libiconv-prefix=/usr/local --program-suffix=34 --with-gxx-include-
dir=/usr/local/lib/gcc/i386-portbld-freebsd4.10/3.4.4/include/c++/ --disable-
shared --prefix=/usr/local i386-portbld-freebsd4.10
Thread model: posix
gcc version 3.4.4 20041210 (prerelease) [FreeBSD]



-- 


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[fnf at specifixinc dot com]

--- Additional Comments From fnf at specifixinc dot com  2004-12-30 16:14 
---
I tried the patch and it does generate a entry:

  <2>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
 DW_AT_abstract_origin: <5f>
 DW_AT_low_pc  : 0x80483a1
 DW_AT_high_pc : 0x80483a6

Note though that this only covers the first instruction of the inlined
subroutine, the mov instr at 80483a1:

 080483a0 :
  80483a0:   55  push   %ebp
  80483a1:   b8 04 00 00 00  mov$0x4,%eax
  80483a6:   89 e5   mov%esp,%ebp

I believe what needs to happen is for the DWARF2 DW_TAG_inlined_subroutine
entry to use the DW_AT_ranges attribute to indentify the discontiguous
address ranges of the inlined subroutine, instead of using DW_AT_low_pc and 
DW_AT_high_pc.

-- 


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

[Bug debug/19191] [4.0 Regression] No DWARF2 DW_TAG_inlined_subroutine entry generated

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-30 
16:42 ---
Subject: Re:  [4.0 Regression] No DWARF2
DW_TAG_inlined_subroutine entry generated

On Thu, 2004-12-30 at 16:14 +, fnf at specifixinc dot com wrote:
> --- Additional Comments From fnf at specifixinc dot com  2004-12-30 16:14 
> ---
> I tried the patch and it does generate a entry:
> 
>   <2>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
>  DW_AT_abstract_origin: <5f>
>  DW_AT_low_pc  : 0x80483a1
>  DW_AT_high_pc : 0x80483a6
> 
> Note though that this only covers the first instruction of the inlined
> subroutine, the mov instr at 80483a1:
> 
>  080483a0 :
>   80483a0:   55  push   %ebp
>   80483a1:   b8 04 00 00 00  mov$0x4,%eax
>   80483a6:   89 e5   mov%esp,%ebp
> 
> I believe what needs to happen is for the DWARF2 DW_TAG_inlined_subroutine
> entry to use the DW_AT_ranges attribute to indentify the discontiguous
> address ranges of the inlined subroutine, instead of using DW_AT_low_pc and 
> DW_AT_high_pc.
> 

Yup.
One problem at a time though.
:)





-- 


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

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
17:27 ---
(In reply to comment #31)
> Subject: Re:  [4.0 Regression] out-of ssa
> causing loops to have more than one BB

> Now if you think that PR is a trivial case that should be caught, then,
> show me why and I'll take a closer look.

The reason why it is not caught is because we don't cleanup the cfg while doing 
the loop optimizations, 
this has been fixed already on the tcb.

Oh, by the way I see that sixtrack has regressed on x86 now with your patch 
applied, I think this is 
because we still have the same problem as before as ivopts puts the new 
instruction in an empty BB
which becomes from not cleaning up the cfg.

-- 


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

[Bug tree-optimization/19042] Complex types are not SRA all the time.

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-12-30 17:42 
---
The patch slightly improves a few SPEC testcases.

-- 


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

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-30 18:39 ---
Subject: Re:  [4.0 Regression] out-of ssa
causing loops to have more than one BB

On Thu, 2004-12-30 at 17:27 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
> 17:27 ---
> (In reply to comment #31)
> > Subject: Re:  [4.0 Regression] out-of ssa
> > causing loops to have more than one BB
> 
> > Now if you think that PR is a trivial case that should be caught, then,
> > show me why and I'll take a closer look.
> 
> The reason why it is not caught is because we don't cleanup the cfg while 
> doing the
> loop optimizations, this has been fixed already on the tcb.
Can you be more precise how cleaning up the CFG during the loop
optimizer affects the code that we see during out-of-ssa.  Specifically
how does it affect PHI arguments on backedges and the proper marking
of backedges in the CFG? 

> 
> Oh, by the way I see that sixtrack has regressed on x86 now with your patch 
> applied, I think this is 
> because we still have the same problem as before as ivopts puts the new 
> instruction in an empty BB
> which becomes from not cleaning up the cfg.
Again, more information please on how this affects us during out-of-ssa?

I'm happy to look into these problems, but you've apparently got a lot
more state on them than I do.  I'd like to learn what you already know
to speed up that process.

jeff




-- 


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

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
18:49 ---
(In reply to comment #33)
> Subject: Re:  [4.0 Regression] out-of ssa
> causing loops to have more than one BB
> > > > Now if you think that PR is a trivial case that should be caught, then,
> > > show me why and I'll take a closer look.
> > 
> > The reason why it is not caught is because we don't cleanup the cfg while 
> > doing the
> > loop optimizations, this has been fixed already on the tcb.
> Can you be more precise how cleaning up the CFG during the loop
> optimizer affects the code that we see during out-of-ssa.  Specifically
> how does it affect PHI arguments on backedges and the proper marking
> of backedges in the CFG? 

It has nothing to do with out-of-ssa any more, sorry for not being clear but 
here are the chain
of events for the current problem.

We split the critial edges so when we try to create the IV (in iv-opts), we 
insert an instruction on the bb 
which is the empty and otherwise useless but if we had cleaned up the CFG 
before running IV-OPTS, we
would insert it right before the condition just like your patch does for out of 
ssa.

And now we have this extra bb that is not useless, out of ssa is going to use 
instead of using your new 
scheme.

-- 


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

[Bug middle-end/19175] [3.4 regression] RTL checking failures on i686-pc-linux-gnu

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-30 
20:23 ---
Subject: Bug 19175

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-30 20:23:29

Modified files:
gcc: ChangeLog loop-unroll.c 

Log message:
PR middle-end/19175
* loop-unroll.c (expand_bct): Pass the code_label to the function
do_compare_rtx_and_jump, not the label ref.  Clean-up style issues.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.758&r2=2.2326.2.759
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-unroll.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.13.4.2&r2=1.13.4.3



-- 


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

[Bug middle-end/19175] [3.4 regression] RTL checking failures on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
20:40 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/19210] New: [4.0 Regression] not using do-loop for some loops

[pinskia at gcc dot gnu dot org]

Take following loop:
int a[22];
void 
f (int n)
{
  int k;
  for(k = 3;k <= n;k++) {
a[k] = k;
  }
}

On the mainline we produce:
L4:
stw r9,0(r2)
addi r9,r9,1
cmpw cr7,r3,r9
addi r2,r2,4
bge+ cr7,L4

But with 3.3.2, we use bdnz:
L9:
slwi r3,r11,2
stwx r11,r3,r9
addi r11,r11,1
bdnz L9

-- 
   Summary: [4.0 Regression] not using do-loop for some loops
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: minor
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-darwin


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
  Known to fail||4.0.0
  Known to work||3.3.2
   Target Milestone|--- |4.0.0


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
20:47 ---
I should note that this comes from sixtrack (or rather from a fortran to C 
converted version of sixtrack).

-- 


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

[Bug debug/19124] [4.0 regression] gcc generates incorrect dwarf2 debug info

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-30 21:01 ---
insn-preds.o was compiled with

stage2/xgcc -Bstage2/ -B/usr/gcc-4.0/i686-pc-linux-gnu/bin/ -c   -O2 -g -fomit-
frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -
Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-
definition -Werror-DHAVE_CONFIG_H-I. -I. -
I/net/gnu/export/gnu/src/gcc/gcc/gcc -I/net/gnu/export/gnu/src/gcc/gcc/gcc/. -
I/net/gnu/export/gnu/src/gcc/gcc/gcc/../include -
I/net/gnu/export/gnu/src/gcc/gcc/gcc/../libcpp/include  insn-preds.c -o insn-
preds.o

It generates

 <1><418c>: Abbrev Number: 47 (DW_TAG_subprogram)
 DW_AT_sibling : <41c6>
 DW_AT_external: 1
 DW_AT_name: (indirect string, offset: 0x3133): 
tls_symbolic_operand
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 471
 DW_AT_prototyped  : 1
 DW_AT_type: <2c>
 DW_AT_low_pc  : 0x2f0
 DW_AT_high_pc : 0x31c
 <2><41a6>: Abbrev Number: 48 (DW_TAG_formal_parameter)
 DW_AT_name: op
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 470
 DW_AT_type: <2dc>
 DW_AT_location: 549(location list)
 <2><41b5>: Abbrev Number: 49 (DW_TAG_formal_parameter)
 DW_AT_name: (indirect string, offset: 0x44e5): mode
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 470
 DW_AT_type: <6be>
 DW_AT_location: 5a2(location list)

0549 02f0 02fe (DW_OP_fbreg: 4)
0549 02fe 0300 (DW_OP_reg0)
0549 0300 0301 (DW_OP_fbreg: 4)
0549 0301 030b (DW_OP_reg0)
0549 030b 0311 (DW_OP_fbreg: 4)
0549 0311 0315 (DW_OP_reg0)
0549 0315 031c (DW_OP_fbreg: 4)

05a2 02f0 02fe (DW_OP_fbreg: 8)
05a2 02fe 031c (DW_OP_reg2)

There is no DW_AT_frame_base. According to DWARF 3 spec, DW_OP_fbreg needs
DW_AT_frame_base.


-- 
   What|Removed |Added

   Keywords|patch   |


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

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
21:50 ---
(In reply to comment #34)
Actually it is because we are placing statements in the loop's latch.
It is done in create_new_iv.

-- 
   What|Removed |Added

   Last reconfirmed|2004-12-20 18:25:23 |2004-12-30 21:50:59
   date||


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

[Bug ada/19211] New: GNAT bug box compiling a-exexda.adb with stage1 compiler

[awreynolds at mac dot com]

stage1/xgcc -Bstage1/ -B/usr/local/ada/powerpc-apple-darwin7.7.0/bin/ -c -g -O2 
-mdynamic-no-
pic  -gnatpg -gnata -g -O1 -fno-inline \
 -I- -I. -Iada -I../../gcc/ada ../../gcc/ada/a-except.adb -o ada/a-except.o
+===GNAT BUG 
DETECTED==+
| 4.0.0 20041230 (experimental) (powerpc-apple-darwin7.7.0) Bus error  |
| Error detected at a-exexda.adb:404:8 |
| 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
Note that list may not be accurate in some cases, 
so please double check that the problem can still 
be reproduced with the set of files listed.

There were no files listed.

-- 
   Summary: GNAT bug box compiling a-exexda.adb with stage1 compiler
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: awreynolds at mac dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.7.0
  GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-12-30 
22:28 ---
Doloop optimizer believes that the loop may be infinite.  There are two ways 
how to prove that this is not the case:

1) k is signed, and thus cannot overflow with -fno-wrapv
2) k cannot run out of the bounds of the array

On rtl level 1) is no longer available.  Using 2) would probably be possible, 
but relatively difficult.

The simplest solution seems to be using information about number of iterations 
computed at tree level.  This is however also a nontrivial project requiring 
changes in many parts of gcc (and at least a few weeks of work), and as such 
this solution cannot be used in 4.0.

-- 


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

[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)

[rakdver at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
22:47 ---
This is a target problem.
Confirmed.

I am looking into how to fix this problem.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|ada |target
 Ever Confirmed||1
  GCC build triplet|powerpc-apple-darwin7.7.0   |
   GCC host triplet|powerpc-apple-darwin7.7.0   |
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2004-12-30 22:47:56
   date||
Summary|GNAT bug box compiling a-   |[4.0 Regression] GNAT bug
   |exexda.adb with stage1  |box compiling a-exexda.adb
   |compiler|with stage1 compiler
   Target Milestone|--- |4.0.0


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

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-30 
23:40 ---
Mine, I think I have a patch.

-- 
   What|Removed |Added

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


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

[Bug c++/19185] [3.3 only] ICE: cp_expr_size, at cp/cp-lang.c:308

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2004-12-31 
00:06 ---
I believe that this error occurs because vax.h defines PCC_STATIC_STRUCT_RETURN.
Removing this define allows the complilation of this file to complete.


-- 


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

[Bug c++/11247] -frepo fails to instantiate typeinfo

[bgreen at nas dot nasa dot gov]

--- Additional Comments From bgreen at nas dot nasa dot gov  2004-12-31 
00:14 ---
I just discovered this bug still exists, in a slightly changed guise.
The previously submitted code now compiles, but a minor change brings the bug
right back.
Attached is the new version of the code that produces the bug.
The diff is essentially this:

< dynamic_cast*>(p);
> IType *p2 = dynamic_cast*>(p);

I'm currently using Gentoo's g++ version 3.4.3.

g++ (GCC) 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)



-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-31 
00:49 ---
Zdenek, I have troubles understanding how such a loop can ever be infinite:

- if wrapv, sooner or later K will reach any N (and thus, surely it will become 
less or equal to any given N).
- if nowrapv, my understanding is that all bets are off: if f() is called with 
N<=3 the loop will terminate, otherwise it's undefined behaviour. In such a 
situation, we can still perform doloop because it's not going to screw the 
program any more than it is already.

What am I missing?

-- 


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
00:54 ---
(In reply to comment #3)
What I don't understand is why this was fine in 3.3.2 and not in 4.0.0 by the 
new do-loop.

-- 


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2004-12-31 00:56 ---
Subject: Re:  [4.0 Regression] not using do-loop for some loops

> Zdenek, I have troubles understanding how such a loop can ever be infinite:
> 
> - if wrapv, sooner or later K will reach any N (and thus, surely it will 
> become 
> less or equal to any given N).
>
> - if nowrapv, my understanding is that all bets are off: if f() is called 
> with 
> N<=3 the loop will terminate, otherwise it's undefined behaviour. In such a 
> situation, we can still perform doloop because it's not going to screw the 
> program any more than it is already.
> 
> What am I missing?

I am afraid your interpretation of the code does not make much sense to
me.  The loop always terminates except for the case when n == MAX_INT
and -fwrapv.  In case n == MAX_INT and -fno-wrapv the behavior is
undefined.


-- 


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

[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2004-12-31 01:29 ---
Subject: Re:  [4.0 Regression] not using do-loop for some loops

> (In reply to comment #3)
> What I don't understand is why this was fine in 3.3.2 and not in 4.0.0 by the 
> new do-loop.

Because the analysis in 3.3.2 is buggy.  Doloop pattern is used even in the
following case (in that there is no problem with undefined behavior):

void
f (unsigned n)
{
  unsigned k;
  for(k = 3;k <= n;k++)
{
}
}

Which is a misscompilation in case n == ~0.


-- 


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

[Bug debug/19212] New: /tmp/ccbY7YyA.s:6435: Error: attempt to get value of unresolved symbol `__s:V151'

[danglin at gcc dot gnu dot org]

/home/dave/gnu/gcc-3.3/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gnu/gcc-3.3/o
bjdir/gcc/ -nostdinc++ -L/home/dave/gnu/gcc-3.3/objdir/vax-ultrix/libstdc++-v3/s
rc -L/home/dave/gnu/gcc-3.3/objdir/vax-ultrix/libstdc++-v3/src/.libs -B/home/dav
e/opt/gnu/vax-ultrix/bin/ -B/home/dave/opt/gnu/vax-ultrix/lib/ -isystem /home/da
ve/opt/gnu/vax-ultrix/include -nostdinc++ -I/home/dave/gnu/gcc-3.3/objdir/vax-ul
trix/libstdc++-v3/include/vax-ultrix -I/home/dave/gnu/gcc-3.3/objdir/vax-ultrix/
libstdc++-v3/include -I../../../../gcc/libstdc++-v3/libsupc++ -I../../../../gcc/
libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite
-strings -fdiagnostics-show-location=once -c ../../../../gcc/libstdc++-v3/src/lo
cale.cc -o locale.o
/tmp/ccbY7YyA.s: Assembler messages:
/tmp/ccbY7YyA.s:6435: Error: attempt to get value of unresolved symbol `__s:V151
'

This reference comes from the following line in the assembler output:

.stabs  "__s:V151",38,0,468,__ZNSt6locale13_S_categoriesE

There is no other reference to `__s:V151' in the file.

I have seen this in the past on this target.  I also see unresolved symbols in 
the .stabs output on hppa*-*-hpux* but there the assembler ignores them.

-- 
   Summary: /tmp/ccbY7YyA.s:6435: Error: attempt to get value of
unresolved symbol `__s:V151'
   Product: gcc
   Version: 3.3.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
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: vax-ultrix


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

[Bug target/19211] [4.0 Regression] GNAT bug box compiling a-exexda.adb with stage1 compiler

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
03:42 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug debug/19212] /tmp/ccbY7YyA.s:6435: Error: attempt to get value of unresolved symbol `__s:V151'

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2004-12-31 
05:52 ---
It seems that the assembler message is somewhat misleading.  The problem
would seem to be due to the fact that the symbol "_ZNSt6locale13_S_categoriesE"
is not output in the .s but the 'V' apparently indicates static storage and
local scope.  This problem doesn't occur at -O0.

(gdb) p debug_tree (decl)
 
unit size 
align 8 symtab 152 alias set -1 precision 8 min  max 
pointer_to_this  reference_to_this <
reference_type 0x401fe690>>
unsigned SI
size 
unit size 
align 32 symtab 151 alias set -1
pointer_to_this  reference_to_this <
reference_type 0x40998310>>
unsigned used SI file /home/dave/gnu/gcc-3.3/objdir/vax-ultrix/libstdc++-v3/
include/bits/basic_string.h line 468 size  unit size 
<
integer_cst 0x4001abe0 4>
align 32 context  abstract_origin  initial 
(mem/s:SI (symbol_ref:SI ("_ZNSt6locale13_S_categoriesE")) [19 
_S_categories+
0 S4 A32])>

(gdb) p debug_rtx (home)
(mem/s:SI (symbol_ref:SI ("_ZNSt6locale13_S_categoriesE")) [19 _S_categories+0 
S4 
A32])


-- 


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

[Bug fortran/17941] gfortran: parser chokes on complex literal constant

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2004-12-31 06:06 ---
The patch here

http://gcc.gnu.org/ml/fortran/2004-12/msg00265.html

fiexes the problem.

-- 


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

[Bug fortran/17941] gfortran: parser chokes on complex literal constant

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-31 
06:08 ---
(In reply to comment #4)
> fiexes the problem.
s/fiexes/fixes/

-- 
   What|Removed |Added

   Keywords||patch


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

Re: Difference in assembly

[Manmeet Singh Johar]

Has anybody faced with such a problem? Please do help me out.
regards
manmeet
Manmeet Singh Johar wrote:
Hello,
I am building cross compilers for SPARC variant for Cygwin and MingW 
hosts. In the process I am faced with a very peculiar problem. For the 
code shown below, though I am getting same assembly instructions in 
same sequence, but the registers used in add are swapped. O0 has no 
problem, but the problem comes in as soon as I compile with O1.
Code:
#include 
extern unsigned int index;
extern unsigned char arr[100];
int main(int argc, char *argv[])
{
   if(arr[index] != 0) printf("\n FATAL") ;
   return 0;
}
I also built the cross compiler for linux and the assembly generated 
matches with the one generated by compiler on Cygwin. Could someone 
please help me out.
Regards
Manmeet


--
Manmeet Singh Johar
Software Engineer
Conexant
(+91-93120-54285)
"Forget yourself and you will not be forgotten."