[Bug other/19165] (Natural) language independent error / warning classification

[walles at mailblocks dot com]

--- Additional Comments From walles at mailblocks dot com  2005-03-29 08:04 
---
That's what they are doing currently, but it works only for English :-(.

-- 


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

[Bug c++/20678] [3.4/4.0/4.1 Regression] Make process stopped

[vladakk at abanka dot co dot yu]

--- Additional Comments From vladakk at abanka dot co dot yu  2005-03-29 
08:06 ---
Oh yeah, now this code is definitly invalid for gcc 3.4.2.
If class contains data members with  __attribute__((packed)) compiler stops
without any warning or error message, with 3.2.3 version this works fine.

-- 


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

[Bug libfortran/20163] gfortran - error opening direct access file

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
08:42 ---
Subject: Bug 20163

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-29 08:41:58

Modified files:
gcc/testsuite  : ChangeLog 
libgfortran: ChangeLog 
libgfortran/io : open.c 
Added files:
gcc/testsuite/gfortran.dg: pr20163-2.f 

Log message:
PR libfortran/20163
* io/open.c (st_open): call library_end() before returning even if
an error arises.

* gfortran.dg/pr20163-2.f: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.71r2=1.5084.2.72
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20163-2.f.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.11r2=1.163.2.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.10.10.1r2=1.10.10.2



-- 


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

[Bug libfortran/20163] gfortran - error opening direct access file

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-03-29 
08:42 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug libfortran/20163] gfortran - error opening direct access file

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
08:37 ---
Subject: Bug 20163

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 08:37:32

Modified files:
gcc/testsuite  : ChangeLog 
libgfortran: ChangeLog 
libgfortran/io : open.c 
Added files:
gcc/testsuite/gfortran.dg: pr20163-2.f 

Log message:
PR libfortran/20163
* io/open.c (st_open): call library_end() before returning even if
an error arises.

* gfortran.dg/pr20163-2.f: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5228r2=1.5229
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20163-2.f.diff?cvsroot=gccr1=NONEr2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.178r2=1.179
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gccr1=1.11r2=1.12



-- 


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

[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-03-29 
09:01 ---
Stupid of me, sorry the noise. If I understand correctly the Standard, INQUIRE
on the existence of a unit should always return TRUE (since we can always open a
unit). The patch may be (testing in progress) as simple as:

Index: inquire.c
===
RCS file: /cvsroot/gcc/gcc/libgfortran/io/inquire.c,v
retrieving revision 1.9
diff -p -u -r1.9 inquire.c
--- inquire.c   30 Jan 2005 13:16:19 -  1.9
+++ inquire.c   29 Mar 2005 07:10:57 -
@@ -46,7 +46,7 @@ inquire_via_unit (gfc_unit * u)
   const char *p;
 
   if (ioparm.exist != NULL)
-*ioparm.exist = (u != NULL);
+*ioparm.exist = 1;
 
   if (ioparm.opened != NULL)
 *ioparm.opened = (u != NULL);

-- 


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

[Bug c++/20679] New: Parse error when accessing attributes of an inner class. Enclosing class is template and have methods with the same name.

[thomas dot claveirole at gmail dot com]

Hello,  
  
$ uname -a  
Linux pc11-169 2.6.10-1-686 #1 Fri Mar 11 03:55:46 EST 2005 i686 GNU/Linux  
$ g++-3.4 --version  
g++-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)  
Copyright (C) 2004 Free Software Foundation, Inc.  
This is free software; see the source for copying conditions.  There is NO  
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  
  
$ cat /tmp/bar.cc  
template class T  
struct foo  
{  
  struct bar  
  {  
int m;  
  };  
  
  // Works if one of these two methods is commented.  
  void  m() const   { }  
  void  m() { }  
  
  bool  n() const   { return b-m  42; }  
  
  bar*  b;  
};  
$ g++-3.4 -c /tmp/bar.cc; echo $?  
/tmp/bar.cc: In member function `bool fooT::n() const':  
/tmp/bar.cc:13: error: missing `' to terminate the template argument list  
/tmp/bar.cc:13: error: parse error in template argument list  
1  
$ g++-3.3 --version  
g++-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-12)  
Copyright (C) 2003 Free Software Foundation, Inc.  
This is free software; see the source for copying conditions.  There is NO  
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  
  
$ g++-3.3 -c /tmp/bar.cc; echo $?  
0  
 
And I am using a Debian unstable. Both g++-3.3 and g++-3.4 come from the 
g++-3.3 and g++-3.4 Debian packages.

-- 
   Summary: Parse error when accessing attributes of an inner class.
Enclosing class is template and have methods with the
same name.
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thomas dot claveirole at gmail 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=20679

[Bug c/20680] New: internal compiler error: in emit_move_insn, at expr.c:2809

[a_gilotra at yahoo dot com]

GCC version:


gcc -v
Reading specs from
/home1/agilotra/gcc-3.4.3-install/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ./configure --prefix=/home1/agilotra/gcc-3.4.3-install
Thread model: posix
gcc version 3.4.3



---
Compiler Error:

/tmp/ranap_append_funcs.c:3584: internal compiler error: in emit_move_insn, at
expr.c:2809
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.




System Type:

Linux rnctest4 2.4.20-20.9-rncpet-7 #1 SMP Mon Oct 18 16:03:52 IST 2004 i686
i686 i386 GNU/Linux


---
Exact Compiler command:

gcc -o obj-file-name -march=pentium3 -O3 -mfpmath=sse -funroll-loops
-minline-all-stringops -ggdb -Wall -pipe -fno-strict-aliasing -c c-file
-Ilist-of-include-files-locations

--

How do I put *.i files ???

-- 
   Summary:  internal compiler error: in emit_move_insn, at
expr.c:2809
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a_gilotra at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/20680] internal compiler error: in emit_move_insn, at expr.c:2809

[a_gilotra at yahoo dot com]

--- Additional Comments From a_gilotra at yahoo dot com  2005-03-29 09:44 
---
Created an attachment (id=8480)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8480action=view)
.i file

.i file generated using -save-temp option

-- 


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

[Bug c/20680] internal compiler error: in emit_move_insn, at expr.c:2809

[a_gilotra at yahoo dot com]

--- Additional Comments From a_gilotra at yahoo dot com  2005-03-29 09:45 
---
Created an attachment (id=8481)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8481action=view)
.s file

.s file generated when used -save-temps option

-- 


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

[Bug c++/20681] New: another wrong control reaches end of non-void function

[oliverst at online dot de]

The following code causes a wrong warning (I couldn't reduce it to less):

#include set

using namespace std;

struct CExtendedEmailInfo {
   bool _s;
};

struct CMetaBitField {
   int _type;
   int GetType() const{
   return _type;
   }
   
   bool operator  (const CMetaBitField) const {
return true;
   }
};

int GetMetaCombination (CExtendedEmailInfo info)
{
 try
 {
  if (info._s)
  {
   setCMetaBitField _bitfields;

   setCMetaBitField::iterator bi;
   if (bi != _bitfields.end())
   {
const CMetaBitField bf = *bi;
switch (bf.GetType())
{
case 0:
 {
  return 17;
 }
 break;

case 1:
 {
  return 18;
 }
 break;

default:
 // really shouldn't happen, but just in case...
 return 0;
}

   }
   else
   {
return 0;
   }
  }
  else
  {
   return 0;
  }
 }
 catch (...)
 {
  return -1;
 }
}

 C:\Dev-Cpp\Projects\test-stlport\main_6.cpp In function 'int
GetMetaCombination(CExtendedEmailInfo)': 
66 C:\Dev-Cpp\Projects\test-stlport\main_6.cpp [Warning] control reaches end of
non-void function 

I am using:

Using built-in specs.
Target: i686-pc-mingw32
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20050324 (prerelease)

-- 
   Summary: another wrong control reaches end of non-void function
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20681] another wrong control reaches end of non-void function warning

[oliverst at online dot de]

-- 
   What|Removed |Added

Summary|another wrong control  |another wrong control
   |reaches end of non-void |reaches end of non-void
   |function   |function warning


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

[Bug c++/20681] another wrong control reaches end of non-void function warning

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-03-29 09:56 
---
Created an attachment (id=8482)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8482action=view)
preprocessed source


-- 


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

[Bug c++/20624] [4.0/4.1 Regression] wrong control reaches end of non-void function warning

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-03-29 09:58 
---
I could isolate the other warning and reduce the soce a bit. I filed it as PR
20681. Could be a duplicate.


-- 


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

[Bug c/20680] [3.4,4.0,4.1 regression] ICE with unit-at-a-time inlining and implicit prototype

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-29 10:45 
---
I can reproduce this with GNU C version 3.4.4 20050314 (prerelease)
(Debian 3.4.3-12) (alpha-linux).

This seems to be cause by unit-at-a-time inlining and implicit prototypes.
4.1 ICEs with
test.c:4: internal compiler error: in fold_convert, at fold-const.c:1921

Test case:

struct S1 { int a, b, c; };
struct S2 { struct S1 s1; };

void f1 (struct S2 *s2) { f2 (s2-s1); }
int  f2 (struct S1 *s1) { return 0; }

Compile with -O3.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
  Known to fail||3.4.4 4.1.0
Summary| internal compiler error: in|[3.4,4.0,4.1 regression] ICE
   |emit_move_insn, at  |with unit-at-a-time inlining
   |expr.c:2809 |and implicit prototype


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

[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-03-29 
10:52 ---
After testing, I proposed this same patch on the mailing-list:
http://gcc.gnu.org/ml/fortran/2005-03/msg00519.html

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-03-29 07:12:59 |2005-03-29 10:52:07
   date||


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

[Bug c++/20682] New: lost parser

[igodard at pacbell dot net]

The attachments are a pair of compiler output/source code runs. The good ones
compile OK; the bad ones report errors. The difference? One blank line of
whitespace. And the reported errors are in a function about ten functions below
where the whitespace change is. Use diff to see where - it's in the second
function named equate(.

I've seen a lot of bugs in gcc, but I don't think I've ever seen one that
depended on whitespace :-)

Ivan

-- 
   Summary: lost parser
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug java/19173] problems resolving classes

[phil at mkdoc dot com]

--- Additional Comments From phil at mkdoc dot com  2005-03-29 11:36 ---
This appears to be a duplicate of bug 10894.

-- 
   What|Removed |Added

 CC||phil at mkdoc dot com


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 11:37 
---
Created an attachment (id=8483)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8483action=view)
compiler output (-v) - bad


-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 11:37 
---
Created an attachment (id=8484)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8484action=view)
compiler output (-v) - good


-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 11:38 
---
Created an attachment (id=8485)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8485action=view)
source code (-save-temps, compressed) - bad


-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 11:38 
---
Created an attachment (id=8486)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8486action=view)
source code (-save-temps, compressed) - good


-- 


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

[Bug java/15377] GCJ does not use the good package for imported classes

[phil at mkdoc dot com]

--- Additional Comments From phil at mkdoc dot com  2005-03-29 11:53 ---
I have seen similar behaviour to this where concrete classes are named after 
their interfaces. I haven't been able to to produce a simple test case. This 
bug 
looks very similar to bug 18796.

-- 
   What|Removed |Added

 CC||phil at mkdoc dot com


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

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[joern dot rennecke at st dot com]

--- Additional Comments From joern dot rennecke at st dot com  2005-03-29 
11:54 ---
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is exporting too many 
symbols

kkojima at gcc dot gnu dot org wrote:

--- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-25 
00:30 ---
joern dot rennecke at st dot com [EMAIL PROTECTED] wrote:
  

FWIW, __mulsi3 should also not be exported, although that is not a
regression.



For the efficiency, yes.  Unfortunately, it causes the binary
compatibility problem for the old binaries refering [EMAIL PROTECTED]
At least, SH linux has too many such binaries already.

Does it, actually?  The mulsi3_call-1 pattern is only used for SH1 code.   


BTW, I could find the use of libgcc-excl.ver in t-linux only.
All targets which make the shared libgcc with the ordinally SH
PIC ABI should use it or similar excl.ver, shouldn't they?

Yes, they should.
   



-- 


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

[Bug middle-end/20263] [4.0/4.1 Regression] Incorrect asm for global register vars

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
12:09 ---
Subject: Bug 20263

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 12:08:55

Modified files:
gcc: ChangeLog varasm.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: sparc-reg-1.c 

Log message:
PR middle-end/20263
* varasm.c (make_decl_rtl) [ASM_DECLARE_REGISTER_GLOBAL]: Use
the DECL_NAME, not the DECL_ASSEMBLER_NAME.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8009r2=2.8010
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.486r2=1.487
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5229r2=1.5230
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/sparc-reg-1.c.diff?cvsroot=gccr1=NONEr2=1.1



-- 


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

[Bug middle-end/20263] [4.0/4.1 Regression] Incorrect asm for global register vars

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
12:18 ---
Subject: Bug 20263

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-29 12:16:41

Modified files:
gcc: ChangeLog varasm.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: sparc-reg-1.c 

Log message:
PR middle-end/20263
* varasm.c (make_decl_rtl) [ASM_DECLARE_REGISTER_GLOBAL]: Use
the DECL_NAME, not the DECL_ASSEMBLER_NAME.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.87r2=2.7592.2.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.477.6.3r2=1.477.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.72r2=1.5084.2.73
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/sparc-reg-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1



-- 


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

[Bug c++/20683] New: wrong warning when using -Woverloaded-virtual

[oliverst at online dot de]

The following code produces a wrong warning:

class A {
public:
virtual ~A() {};
virtual void Update( int ) {};
protected:
virtual void Update( int, float ) {};
};

class B : public A {
public: 
virtual void Update( int ) {};
};

6 C:\Dev-Cpp\Projects\test-stlport\main_7.cpp [Warning] 'virtual void
A::Update(int, float)' was hidden 
11 C:\Dev-Cpp\Projects\test-stlport\main_7.cpp [Warning]   by 'virtual void
B::Update(int)' 

I thought the warnign was only supposed to happen, if B has no virtual in front
of the function Update, which is inherited from A.

I am using:

Using built-in specs.
Target: i686-pc-mingw32
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20050324 (prerelease)

-- 
   Summary: wrong warning when using -Woverloaded-virtual
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20683] wrong warning when using -Woverloaded-virtual

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-03-29 12:19 
---
Created an attachment (id=8487)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8487action=view)
preprocessed source


-- 


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

[Bug middle-end/20263] [4.0/4.1 Regression] Incorrect asm for global register vars

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
12:23 ---
Fixed in 4.x.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug java/20684] New: FileChannelImpl.java fails to sync filedescriptor on force() invocation

[martin at egholm-nielsen dot dk]

The implementation of java.nio.channels.FileChannel in present CVS head (as of
2005-03-29) gcc/libjava/gnu/java/nio/channels/FileChannelImpl.java does not
obey the contract for #force(boolean), which states that is should
flush/synchronize the channel's file with the storage device.

However, the implementation (in Revision 1.6.32.2, at least) does nothing like 
it:

  public void force (boolean metaData) throws IOException
  {
if (!isOpen ())
  throw new ClosedChannelException ();
  }

-- 
   Summary: FileChannelImpl.java fails to sync filedescriptor on
force() invocation
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at egholm-nielsen dot dk
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org,konqueror at gmx dot de


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

[Bug fortran/13082] Function entries and entries with alternate returns not implemented

[alfredo dot ferrari at cern dot ch]

--- Additional Comments From alfredo dot ferrari at cern dot ch  2005-03-29 
12:34 ---
Hi, any news on this bug? I really appreciate the effort to build a free
fortran95 compiler: the need for this is really strongly felt in our community.
However, without working ENTRY's, gfortran is going to be of little use for the
vast majority of the fortran particle physics and mathematics code we are using
here at CERN and probably around the world. As ugly as it is (and I can assure
that often it was the nicest way rather than the ugliest one of doing things)
ENTRY is part of the standard and most fortran codes (at least in particle
physics) make often use of it in endless places. This is true both for legacy
codes where putting hands would be highly problematic, and for codes still in
active development.
I am afraid I can be of little help in providing patches/improvements since I am
a physicist with no experience in compiler writing and/or assembler. However I
have a long experience in finding bugs, reporting them and helping in assessing
possible solutions, dating back to the old time of VMS machines.
Please don't let us down, we fought a lot to have Linux as primary platform for
physics calculations, and we want to be able to demonstrate that is was and it
will be a viable and stable solution.

-- 


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

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[kkojima at gcc dot gnu dot org]

--- Additional Comments From kkojima at gcc dot gnu dot org  2005-03-29 
12:43 ---
joern dot rennecke at st dot com [EMAIL PROTECTED] wrote:
 Does it, actually?  The mulsi3_call-1 pattern is only used for SH1 code.   

Ah, you are right.  Sorry for my mess.


-- 


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

[Bug c++/20685] New: another wrong warning when using -Woverloaded-virtual

[oliverst at online dot de]

I filed a new bug report for this, because it does happen with same name, but
different parameters. The first one I filed was with same name and same 
parameters.

class A {
public:
virtual ~A() {}
virtual bool LinkData(int**, int) { return true; }
};

class B : public A {
public:
virtual bool LinkData(int, float, int) { return true; }
};

Using built-in specs.
Target: i686-pc-mingw32
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20050324 (prerelease)

-- 
   Summary: another wrong warning when using -Woverloaded-virtual
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20685] another wrong warning when using -Woverloaded-virtual

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-03-29 12:57 
---
Sorry, forgot the warning:

4 C:\Dev-Cpp\Projects\test-stlport\main_8.cpp [Warning] 'virtual bool
A::LinkData(int**, int)' was hidden 
9 C:\Dev-Cpp\Projects\test-stlport\main_8.cpp [Warning]   by 'virtual bool
B::LinkData(int, float, int)' 

-- 


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

[Bug c++/20685] another wrong warning when using -Woverloaded-virtual

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-03-29 12:58 
---
Created an attachment (id=8488)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8488action=view)
preprocessed source


-- 


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

[Bug target/20625] [4.0 regression] ivopts produces code that generates unaligned access exception

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-29 13:03 
---
I can reproduce this with gcc 4.0.0 20050329 on alphaev68-unknown-linux-gnu.
Test case:

struct BS {
int i;
char c[46];
};

void foo(struct BS* p)
{   
int i; 
for (i = 0; p-c[i]; i++) 
; 
}

int main()
{
#if defined(__alpha__)  defined(__linux__)
#include asm/sysinfo.h
#include asm/unistd.h
unsigned int buf[2] = { SSIN_UACPROC, UAC_SIGBUS | UAC_NOPRINT };
syscall(__NR_osf_setsysinfo, SSI_NVPAIRS, buf, 1, 0, 0, 0);
#endif

struct BS p = { 0, 12 };
foo(p);
return 0;
}

[EMAIL PROTECTED]:/tmp% gcc -mcpu=ev4 -O2 t.c  ./a.out
zsh: bus error (core dumped)  ./a.out
[EMAIL PROTECTED]:/tmp% gcc -fno-ivopts -mcpu=ev4 -O2 t.c  ./a.out 
[EMAIL PROTECTED]:/tmp% 


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0
Summary|gcc with -O2 produces code  |[4.0 regression] ivopts
   |that generates unaligned   |produces code that generates
   |access exception   |unaligned access exception


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

[Bug target/20625] [4.0 regression] ivopts produces code that generates unaligned access exception

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-29 13:12 
---
This looks similar to the (fixed) PR 17949. Zdenek, do you have any ideas?


-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug middle-end/20648] [4.0/4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-29 
13:22 ---
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02578.html

-- 


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

[Bug middle-end/20674] unexpected result from floating compare

[piaget at us dot ibm dot com]

--- Additional Comments From piaget at us dot ibm dot com  2005-03-29 13:42 
---
(In reply to comment #10)

 Except, the value could have been spilled and reloaded from registers
 between those two source lines, which on x86, is where the problem comes
 from.
 The problem is no different simply because the *source* lines happen to
 be right next to each other.

I would have expected a compiler to identify these situations and produce code 
that logically matches the code being compiled. If this is not the case, then 
maybe -ffloat-store should be the default behavior with appropriate warnings 
about turning -ffloat-store off.



-- 


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

[Bug c/20680] [3.4,4.0,4.1 regression] ICE with unit-at-a-time inlining and implicit prototype

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
14:04 ---
Yes with unit-at-a-time this shows up but really this is a latent bug and is a 
dup of bug 16876.
The code is undefined as you are passing the wrong types.  (This is why 
implicit prototypes are bad).

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/16876] [3.3/3.4/4.0/4.1 Regression] ICE on testcase with -O3 in gen_lowpart

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||a_gilotra at yahoo dot com


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

[Bug debug/20446] [4.0/4.1 Regression] invalid assembly with -gstabs+

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
14:08 ---
Workaround: -fdelayed-branch (enabled at -O and above).


-- 


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

[Bug c++/20683] wrong warning when using -Woverloaded-virtual

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
14:10 ---
Actually the warning is correct.
This is a dup of bug 20423 which has not been closed yet because I did not want 
to close it yet and 
there could be a better warning message.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/20423] Warning -Woverloaded-virtual triggers to often

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
14:10 ---
*** Bug 20683 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||oliverst at online dot de


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

[Bug java/19173] problems resolving classes

[ora dot et dot labora at web dot de]

--- Additional Comments From ora dot et dot labora at web dot de  
2005-03-29 14:12 ---
(In reply to comment #2)
 This appears to be a duplicate of bug 10894.

I think you are correct - looks like I missed entry 19173. Nevertheless, I like
my entry because my entry is short, clear and precise. 

Will this bug ever be fixed?

-- 


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

[Bug c++/20685] another wrong warning when using -Woverloaded-virtual

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
14:15 ---
This warning is what -Woverloaded-virtual is about in the first place.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/20674] unexpected result from floating compare

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
14:17 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

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

-- 


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

[Bug c++/20679] [3.4/4.0/4.1 Regression] Parse error when accessing attributes of an inner class. Enclosing class is template and have methods with the same name.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
14:22 ---
Confirmed, something is definitely wrong.  This is most likely related to PR 
10200.

-- 
   What|Removed |Added

  BugsThisDependsOn||10200
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-03-29 14:22:02
   date||
Summary|Parse error when accessing  |[3.4/4.0/4.1 Regression]
   |attributes of an inner  |Parse error when accessing
   |class. Enclosing class is   |attributes of an inner
   |template and have methods   |class. Enclosing class is
   |with the same name. |template and have methods
   ||with the same name.
   Target Milestone|--- |3.4.4


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

[Bug fortran/20686] New: ICE in gfc_conv_ss_descriptor

[jakub at gcc dot gnu dot org]

implicit none
integer, dimension(2) :: i,j
i=(/1,2/)
j=i((/2,1/))
end

./gfortran -m32 -B ./ -c 151275.f95
151275.f95: In function 'MAIN__':
151275.f95:3: internal compiler error: in gfc_conv_ss_descriptor, at
fortran/trans-array.c:1224
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.

-- 
   Summary: ICE in gfc_conv_ss_descriptor
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/16876] [3.3/3.4/4.0/4.1 Regression] ICE on testcase with -O3 in gen_lowpart

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-29 14:58 
---
See also my notes http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html on
what should receive warnings (possibly compiled into aborts), what should
receive errors and how c_convert_parm_for_inlining (a) is too late for such
diagnostics and (b) fails actually to carry out the conversion or diagnostics
in certain cases.


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug libfortran/20661] End of record not detected

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-03-29 
15:11 ---
I'll try and have a look.

Hopefully, my copyright papers that I sent off on 2005-03-19 will
come through sometime soon, because the end-of-record patch
at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html (or
something that does the same job) needs to be applied before
going into this one.

Thomas

-- 


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

[Bug middle-end/20622] [4.0/4.1 Regression] Alias to nocommon variable fails to assemble on ppc64

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
15:37 ---
Subject: Bug 20622

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 15:37:29

Modified files:
gcc: ChangeLog varasm.c cgraph.c cgraph.h toplev.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: alias-7.c 

Log message:
PR middle-end/20622
* cgraph.h (struct cgraph_varpool_node): Add alias field.
* cgraph.c (cgraph_varpool_assemble_pending_decls): Don't call
assemble_variable on aliases.
* varasm.c (assemble_alias): Set node-alias.
* toplev.c (wrapup_global_declarations): Don't call
rest_of_decl_compilation on aliases again.

* gcc.dg/alias-7.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8011r2=2.8012
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.487r2=1.488
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.c.diff?cvsroot=gccr1=1.68r2=1.69
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gccr1=1.46r2=1.47
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gccr1=1.948r2=1.949
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5230r2=1.5231
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/alias-7.c.diff?cvsroot=gccr1=NONEr2=1.1



-- 


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

[Bug fortran/20686] ICE in gfc_conv_ss_descriptor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
15:37 ---
This is a dup of bug 12366.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/20622] [4.0/4.1 Regression] Alias to nocommon variable fails to assemble on ppc64

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
15:41 ---
Subject: Bug 20622

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-29 15:41:04

Modified files:
gcc: ChangeLog varasm.c cgraph.c cgraph.h toplev.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: alias-7.c 

Log message:
PR middle-end/20622
* cgraph.h (struct cgraph_varpool_node): Add alias field.
* cgraph.c (cgraph_varpool_assemble_pending_decls): Don't call
assemble_variable on aliases.
* varasm.c (assemble_alias): Set node-alias.
* toplev.c (wrapup_global_declarations): Don't call
rest_of_decl_compilation on aliases again.

* gcc.dg/alias-7.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.88r2=2.7592.2.89
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.477.6.4r2=1.477.6.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.64.8.2r2=1.64.8.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.44.8.1r2=1.44.8.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.944.2.1r2=1.944.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.73r2=1.5084.2.74
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/alias-7.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1



-- 


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

[Bug middle-end/20622] [4.0/4.1 Regression] Alias to nocommon variable fails to assemble on ppc64

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-03-29 15:44 
---
Fixed in CVS.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
15:59 ---
One thing, this is definitely invalid code:
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_baselong unsigned int, std::allocatorlong 
unsigned int ::anonymous enumâ is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplateclass T templateclass Arg T operator+(T, Arg)
â

Well the reduced testcase might not be though.

-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
16:01 ---
The code around the problem:
 typedef typeof(to(0, models.size())) i_t386;
  i_t386 a;

-- 


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

[Bug ada/20300] ICE on undefined value of type derived from Character

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
16:20 ---
Subject: Bug 20300

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 16:15:46

Modified files:
gcc/ada: exp_intr.adb Makefile.rtl impunit.adb 
 snames.ads snames.adb sem_ch8.adb 
Added files:
gcc/ada: a-tgdico.ads 

Log message:
2005-03-29  Gary Dismukes  [EMAIL PROTECTED]
Robert Dewar  [EMAIL PROTECTED]

* exp_intr.adb (Expand_Dispatching_Constructor_Call): New procedure to
expand a call to an instance of
Ada.Tags.Generic_Dispatching_Constructor into a dispatching call to the
Constructor actual of the instance. A class-wide membership
check is also generated, to ensure that the tag passed to the instance
denotes a type in the class.
(Expand_Intrinsic_Call): Call Expand_Dispatching_Constructor in the case
of Name_Generic_Dispatching_Constructor.

* Makefile.rtl: Add a-tgdico.ads to the list of library units (new Ada
05 unit for AI-260-02).

* a-tgdico.ads: New file.

* impunit.adb (Non_Imp_File_Names_05): Add entry a-tgdico for new
predefined Ada 05 generic unit Ada.Tags.Generic_Dispatching_Constructor.

* snames.ads, snames.adb (Preset_Names): Add entry for
Generic_Dispatching_Constructor.

PR ada/20300

* sem_ch8.adb (Find_Direct_Name): Go to root type for check of
character type cases.
(Analyze_Subprogram_Renaming): Add special handling for
the case of renaming of stream attributes when the renaming denotes a
generic formal subprogram association for an abstract formal subprogram.
Check that the attribute is a primitive stream attribute (and not
a class-wide stream attribute) and then rewrite the attribute name
as the name of the appropriate compiler-generated stream primitive.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/a-tgdico.ads.diff?cvsroot=gccr1=NONEr2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/exp_intr.adb.diff?cvsroot=gccr1=1.11r2=1.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.rtl.diff?cvsroot=gccr1=1.13r2=1.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/impunit.adb.diff?cvsroot=gccr1=1.17r2=1.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/snames.ads.diff?cvsroot=gccr1=1.37r2=1.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/snames.adb.diff?cvsroot=gccr1=1.36r2=1.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/sem_ch8.adb.diff?cvsroot=gccr1=1.32r2=1.33



-- 


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

[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
16:26 ---
Subject: Bug 19956

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 16:21:57

Modified files:
gcc/ada: utils.c 

Log message:
2005-03-29  Richard Kenner  [EMAIL PROTECTED]

PR ada/19956
* utils.c (finish_record_type): Use variable_size when setting sizes.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/utils.c.diff?cvsroot=gccr1=1.93r2=1.94



-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug ada/20300] ICE on undefined value of type derived from Character

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-29 
16:29 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
16:38 ---
I'll backport the fix to 4.0 as per Richard's request.

-- 
   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug c++/20687] New: namespace bug

[jozef at syncad dot com]

From the example in 7.3.4.1 (international standard
ISO/IEC 14882) we can conclude that
 the names introduced by using directive hide
 the names in higer level namespaces instead of
 resulting in an ill-formed code.
In the source code attached __false_type should
 be recognized correctly as comming from namespace
 _STL and should not conflict with the top level
 definition of __false_type. This is so since
 namespace std contains using namepsace _STL and
 the namespace _STL contains definition of
 __false_type too. 

Below is part of preprocesed file

$ gcc --version
gcc (GCC) 4.0.0 20050319 (prerelease)

compile command :
c++  -pthread -fexceptions -I../stlport -W -Wno-sign-compare \
 -Wno-unused -Wno-uninitialized -D_STLP_USE_GLIBC \
 -O0 -gstabs+ -g3 -fPIC -D_STLP_DEBUG -fPIC complex_exp.cpp \
 -c -o ../lib/obj/GCC-LINUX/DebugSTLD/complex_exp.o

next was cut from preprocesed complex_exp.i.cpp:
namespace std { }
namespace __std_alias = std;

namespace _STL {}
namespace std {
  using namespace _STL;
}

namespace _STL {
using namespace __std_alias;
}

namespace _STL {
struct __true_type {};
struct __false_type {};

template int _Is struct __bool2type {
  typedef __false_type _Ret;// this is OK
};
template
struct __bool2type1 { typedef __true_type _Ret; };// this is OK
}

namespace _STL {}
namespace std {
  using namespace _STL;
}

struct __true_type { };
struct __false_type { };

namespace std
{
  templatebool
struct __truth_type
{ typedef __false_type __type; };   // should be OK too, but report error:
'__false_type' does not name a type

  template
struct __truth_typetrue
{ typedef __true_type __type; };// should be OK too, but report error:
'__true_type' does not name a type

}

Whole file is too long (2 row) - if it is needed please let me know,
I will send it.

(OS is Fedora core 3 at Linux kernel 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004
i686 i686 i386 GNU/Linux)

-- 
   Summary: namespace bug
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jozef at syncad dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20621] ICE: in change_address_1, at emit-rtl.c:1886

[ldarby at mips dot com]

--- Additional Comments From ldarby at mips dot com  2005-03-29 17:34 
---
It still appears in the latest native mips compiler.

$ gcc --version
gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)

Have you got binaries for the cross compiler you're using?


-- 


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

[Bug tree-optimization/20626] [4.1 Regression] vect-80.c and vect-96.c fail on ia64-hpux

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-03-29 17:51 
---
Fixed with change to testsuite.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug ada/19956] [4.0 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
18:48 ---
Kenner thanks for looking into and fixing this.
Moving target to 4.0 as this justs a back porting, remove 4.1 regression marker 
from the summary.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|middle-end  |ada
Summary|[4.0/4.1 Regression] ICE|[4.0 Regression] ICE
   |copy_tree_r, at tree-   |copy_tree_r, at tree-
   |inline.c:2320 on simple Ada |inline.c:2320 on simple Ada
   |code|code
   Target Milestone|4.1.0   |4.0.0


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

[Bug pch/20315] pch problems on solaris

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
18:54 ---
Maybe this can be fixed by disabling PCH generation when -x is passed.


-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-29 18:54:09
   date||


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

[Bug c/20672] [4.1 Regression] New C parser doesn't check whether functions that end files are closed properly

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
18:55 ---
Subject: Bug 20672

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 18:54:45

Modified files:
gcc: ChangeLog c-parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20672-1.c 

Log message:
PR c/20672
* c-parser.c (c_parser_compound_statement_nostart): Give error
message for EOF instead of just setting parser-error.

testsuite:
* gcc.dg/pr20672-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8015r2=2.8016
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parser.c.diff?cvsroot=gccr1=2.8r2=2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5232r2=1.5233
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20672-1.c.diff?cvsroot=gccr1=NONEr2=1.1



-- 


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

[Bug other/18936] GCC gives internal error and uses all sytem ram before doing so.

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
18:56 ---
No feedback in 3 months.


-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/19184] Octave compilation is failing during running make

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
18:58 ---
No feedback in 3 months.


-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c/20672] [4.1 Regression] New C parser doesn't check whether functions that end files are closed properly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
19:10 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/20611] [3.4 only] duplicate label for inlined function referencing TLS

[janis at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug target/20611] duplicate label for inlined function referencing TLS

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
19:15 ---
I figured that this could be a bug in the mainline still.

-- 
   What|Removed |Added

Summary|[3.4 only] duplicate label  |duplicate label for inlined
   |for inlined function|function referencing TLS
   |referencing TLS |
   Target Milestone|3.4.4   |---


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[chris at bubblescope dot net]

--- Additional Comments From chris at bubblescope dot net  2005-03-29 19:19 
---
A friend of mine was recently caught by this bug.. is there any chance it could
be fixed now? or is there still some problem holding it up (or just no-one
cares?). Although I am by no means certain, I imagine it's possible that this
might be increased by the upcoming TR1 library, so it might be nice to get the
value correct.

-- 


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
19:19 ---
Confirmed in 3.4.x, probably another incarnation of the infamous stack slot
sharing problem in 3.x when type-based aliasing is enabled.

As as side note, -fschedule-insns makes little sense without -mcpu=xxx on SPARC.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.3.2 3.4.3 3.4.4
  Known to work||2.95 4.0.0 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-03-29 19:19:23
   date||
Summary|-fstrict-aliasing causes|[3.4 Regression] -fstrict-
   |incorrect scheduling on |aliasing causes incorrect
   |Sparc Solaris   |scheduling
   Target Milestone|--- |3.4.4


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

[Bug middle-end/20621] ICE: in change_address_1, at emit-rtl.c:1886

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
19:32 ---
(In reply to comment #6)
 It still appears in the latest native mips compiler.
 Have you got binaries for the cross compiler you're using?
Well considering it is a cross from powerpc-darwin, I really doubt it would be 
useful to you.

-- 


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

[Bug bootstrap/14316] collect2 doesnt build on windows hosts

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
19:39 ---
Subject: Bug 14316

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 19:39:36

Modified files:
gcc: ChangeLog collect2.c collect2.h tlink.c 

Log message:
PR bootstrap/14316
* collect2.c: Never include vfork.h.
(VFORK_STRING, vfork): Don't define.
(pid): Remove global variable.
(handler): Call raise instead of kill (getpid(), ...).
(collect_wait): Add pex parameter.  Change all callers.  Use
pex_get_status rather than pwait.
(do_wait): Add pex parameter.  Change all callers.
(collect_execute): Return struct pex_obj * rather than void.  Use
pex routines rather than pexecute.
(fork_execute): Get pex_obj from collect_execute, and pass it to
do_wait.
(scan_prog_file): Use pex routines rather than pipe/vfork/exec.
Only declare quit_handler if SIGQUIT is defined.
(scan_libraries): Likewise.
* collect2.h (collect_execute): Update declaration.
(collect_wait): Update declaration.
* tlink.c (tlink_execute): Get pex_obj from collect_execute, and
pass it to collect_wait.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8016r2=2.8017
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/collect2.c.diff?cvsroot=gccr1=1.170r2=1.171
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/collect2.h.diff?cvsroot=gccr1=1.10r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tlink.c.diff?cvsroot=gccr1=1.59r2=1.60



-- 


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

[Bug target/20608] Bus Error - union of structures

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
19:41 ---
The code is invalid: you're dereferencing a t_m pointer through a cast to
pointer to t_u.  Now the structures don't have the same alignment (t_m is 32-bit
aligned while t_u is 64-bit aligned).  I guess this accidentally worked in 3.4.x
because u was overaligned on the stack.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-29 
19:43 ---
Investigating.


-- 
   What|Removed |Added

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


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

[Bug c++/20687] namespace bug

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
19:51 ---
The reduced testcase:
namespace dd {
struct t1 {};
}
namespace ff {
  using namespace dd;
}
struct t1 { };
namespace ff
{
 typedef t1 t2;
}


But the use of t1 is ambiguous really as using namespace is not as strong as 
defining the t1 in the 
namespace ff or doing a using dd::t1 in the namespace ff.

-- 


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

[Bug c++/20687] namespace bug

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
19:56 ---
But look at the example for 7.3.4 P5 and you will see that this is in fact 
invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates unaligned access exception

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
20:03 ---
This most likely can be reproduced on ia64 too and other targets where 
alignment is needed for some 
loads.

The tree which we produce looks like:
bb 0:
  if (p-c[0] != 0) goto L0; else goto L2;

L0:;
  D.1133 = *((unsigned char *) p + 5B);
  p = p + 1B;
  if (D.1133 != 0) goto L0; else goto L2;

-- 
   What|Removed |Added

Summary|[4.0 regression] ivopts |[4.0/4.1 regression] ivopts
   |produces code that generates|produces code that generates
   |unaligned access exception|unaligned access exception
   Target Milestone|--- |4.0.0


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

[Bug c++/20681] [4.0/4.1 Regression] wrong control reaches end of non-void function warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
20:13 ---
Reduced testcase:
struct a{~a();a();};
int GetMetaCombination (int a2)
{
  a bi;
  switch (a2)
  {
case 1:
  return 18;
  break;//removing this works around the warning
default:
  return 0;
  }
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-03-29 20:13:16
   date||
Summary|another wrong control  |[4.0/4.1 Regression] wrong
   |reaches end of non-void |control reaches end of non-
   |function warning   |void function warning
   Target Milestone|--- |4.0.1


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates unaligned access exception

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-03-29 20:23 
---
(In reply to comment #6)
 This most likely can be reproduced on ia64 too and other targets where
alignment is needed for some 
 loads.

I cannot reproduce it with -mcpu=ev56, though, so maybe it needs a plaform
that does not have narrow loads (do we have any other except alphaev4?).

-- 


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

Mail Delivery (failure gcc-bugs@gcc.gnu.org)

[bkoz]

This is a multi-part message in MIME format.
Norman Virus Control a supprimé le message original qui contenait le virus 
[EMAIL PROTECTED]

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates unaligned access exception

[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  2005-03-29 20:47 ---
Subject: Re:  [4.0/4.1 regression] ivopts produces code that generates 
unaligned access exception

 This most likely can be reproduced on ia64 too and other targets where 
 alignment is needed for some 
 loads.
 
 The tree which we produce looks like:
 bb 0:
   if (p-c[0] != 0) goto L0; else goto L2;
 
 L0:;
   D.1133 = *((unsigned char *) p + 5B);
   p = p + 1B;
   if (D.1133 != 0) goto L0; else goto L2;

The problem seems to be that the expansion assumes that p must be
aligned.  Which seems to be reasonable.  I will try making ivopts
produce all pointer ivs in (void *) type, that should hopefully
help.


-- 


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

[Bug target/20650] [4.1 Regression] float.c fails to build with weird error message

[geoffk at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 21:03 
---
Re comment #5: I don't get the messages reported by Andrew, and I really rather
doubt that those messages (form a different compiler version than I'm using) are
legit. They are flagging stuff inside a stock boost library, and I have some
confidence that boost stuff is OK. Looks to me that whatever the bug is it
causes the compiler to start complaining at a random point in the source - with
my 3.4.0 the complaint is in my own code, with Andrew's it's in a boost library,
but both complaints are bogus.

Just a suspicion.



-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates unaligned access exception

[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  2005-03-29 21:09 ---
Subject: Re:  [4.0/4.1 regression] ivopts produces code that generates 
unaligned access exception

  This most likely can be reproduced on ia64 too and other targets where 
  alignment is needed for some 
  loads.
  
  The tree which we produce looks like:
  bb 0:
if (p-c[0] != 0) goto L0; else goto L2;
  
  L0:;
D.1133 = *((unsigned char *) p + 5B);
p = p + 1B;
if (D.1133 != 0) goto L0; else goto L2;
 
 The problem seems to be that the expansion assumes that p must be
 aligned.  Which seems to be reasonable.  I will try making ivopts
 produce all pointer ivs in (void *) type, that should hopefully
 help.

This patch should fix the problem (I have looked on crosscompiler
output only, so I am not entirely sure yet).

Index: tree-ssa-loop-ivopts.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-ivopts.c,v
retrieving revision 2.54
diff -c -3 -p -r2.54 tree-ssa-loop-ivopts.c
*** tree-ssa-loop-ivopts.c  22 Mar 2005 22:08:53 -  2.54
--- tree-ssa-loop-ivopts.c  29 Mar 2005 21:07:33 -
*** strip_offset (tree expr, bool inside_add
*** 1840,1845 
--- 1840,1861 
return fold_convert (orig_type, expr);
  }
  
+ /* Returns variant of TYPE that can be used as base for different uses.
+For integer types, we return unsigned variant of the type, which
+avoids problems with overflows.  For pointer types, we return void *.  */
+ 
+ static tree
+ generic_type_for (tree type)
+ {
+   if (POINTER_TYPE_P (type))
+ return ptr_type_node;
+ 
+   if (TYPE_UNSIGNED (type))
+ return type;
+ 
+   return unsigned_type_for (type);
+ }
+ 
  /* Adds a candidate BASE + STEP * i.  Important field is set to IMPORTANT and
 position to POS.  If USE is not NULL, the candidate is set as related to
 it.  If both BASE and STEP are NULL, we add a pseudocandidate for the
*** add_candidate_1 (struct ivopts_data *dat
*** 1852,1865 
  {
unsigned i;
struct iv_cand *cand = NULL;
!   tree type;

if (base)
  {
!   type = TREE_TYPE (base);
!   if (!TYPE_UNSIGNED (type))
{
- type = unsigned_type_for (type);
  base = fold_convert (type, base);
  if (step)
step = fold_convert (type, step);
--- 1868,1881 
  {
unsigned i;
struct iv_cand *cand = NULL;
!   tree type, orig_type;

if (base)
  {
!   orig_type = TREE_TYPE (base);
!   type = generic_type_for (orig_type);
!   if (type != orig_type)
{
  base = fold_convert (type, base);
  if (step)
step = fold_convert (type, step);


-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
21:11 ---
(In reply to comment #7)
 Re comment #5: I don't get the messages reported by Andrew, and I really 
 rather
 doubt that those messages (form a different compiler version than I'm using) 
 are
 legit. They are flagging stuff inside a stock boost library, and I have some
 confidence that boost stuff is OK. Looks to me that whatever the bug is it
 causes the compiler to start complaining at a random point in the source - 
 with
 my 3.4.0 the complaint is in my own code, with Andrew's it's in a boost 
 library,
 but both complaints are bogus.

The error messages are correct as far as I know.  I am using the mainline (as 
of a couple of days ago).
The error in Boost I think are fixed in a newer version of Boost.
I will try to reduce this later tonight, it just will take me a while because I 
have to remove all the invalid 
code.

-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 21:19 
---
Andrew - can you confirm getting the same problem I do if you run it in 3,4,0?


-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
21:25 ---
(In reply to comment #9)
 Andrew - can you confirm getting the same problem I do if you run it in 3,4,0?

yes which is why I pointed out in comment #6 the code around where the problem 
is.

-- 


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

[Bug c/20688] New: [x86-64] gcc miscompiles composition of sqrt() with inlined function

[cvogler2001 at yahoo dot com]

GCC info: gcc -v

Reading specs from
/home/cvogler/addons/gcc-test/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/home/cvogler/addons/gcc-test
--disable-multilib
Thread model: posix
gcc version 3.4.3

The following test snippet shows a very reduced case of Cholesky factorization
code, which uses inline functions for array indexing. It is miscompiled with
these compiler flags on the x86_64 target:

gcc -Wall -O -finline-functions -o test test.c -lm

--- test.c ---
#include math.h

double getval()
{
  return -1.0;
}

int main(void)
{
  double y = sqrt(getval());
}
---

The result is in infinite loop, instead of the expected nan. This generated
assembler snippet, in particular, looks incorrect:

---
.L3:
sqrtsd  %xmm0, %xmm0
ucomisd %xmm0, %xmm0
jp  .L6
je  .L4
.L6:
movlpd  .LC3(%rip), %xmm0
jmp .L3
.L4:
rep ; ret
---

In this snippet .L6 should contain a call to the sqrt function, but instead it
jumps back to .L3, causing an infinite loop. Suppressing inlining of functions
makes gcc generate correct code. Also, I could not reproduce the problem on a
32-bit x86 target.

-- 
   Summary: [x86-64] gcc miscompiles composition of sqrt() with
inlined function
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cvogler2001 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c/20688] [x86-64] gcc miscompiles composition of sqrt() with inlined function

[cvogler2001 at yahoo dot com]

--- Additional Comments From cvogler2001 at yahoo dot com  2005-03-29 21:29 
---
Created an attachment (id=8491)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8491action=view)
Preprocessed test snippet for reproducing the bug


-- 


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

[Bug tree-optimization/20688] [3.4 Regression] gcc miscompiles composition of sqrt() with inlined function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
21:36 ---
Fixed already in 3.4.4.
This might be a dup of another bug somewhere too.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |tree-optimization
   Keywords||wrong-code
 Resolution||FIXED
Summary|[x86-64] gcc miscompiles|[3.4 Regression] gcc
   |composition of sqrt() with  |miscompiles composition of
   |inlined function|sqrt() with inlined function
   Target Milestone|--- |3.4.4


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
21:36 ---
Subject: Bug 20491

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 21:36:10

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: asm-subreg-1.c 

Log message:
PR middle-end/20491
* gcc.dg/torture/asm-subreg-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5233r2=1.5234
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c.diff?cvsroot=gccr1=NONEr2=1.1


--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
21:36 ---
Subject: Bug 20491

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-29 21:36:20

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: asm-subreg-1.c 

Log message:
PR middle-end/20491
* gcc.dg/torture/asm-subreg-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.74r2=1.5084.2.75
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1



-- 


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
21:36 ---
Subject: Bug 20491

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-29 21:36:10

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: asm-subreg-1.c 

Log message:
PR middle-end/20491
* gcc.dg/torture/asm-subreg-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5233r2=1.5234
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c.diff?cvsroot=gccr1=NONEr2=1.1



-- 


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