[Bug target/17836] [4.0 Regression] ABI breakage for 16-byte vectors (non-Altivec ABI & ISA)

[paolo dot bonzini at polimi dot it]

--- Additional Comments From paolo dot bonzini at polimi dot it  2004-10-11 07:18 
---
Subject: Re:  [4.0 Regression] ABI breakage for 16-byte
 vectors (non-Altivec ABI & ISA)

> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-10 20:27 
> ---
> Causes these two tests to fail on ppc:
> FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o compile
> FAIL: gcc.dg/compat/vector-2 c_compat_y_tst.o compile

No, it failed even before.  Actually, the bug is masking the failure in 
vector-1.c

 From http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00015.html:

FAIL: gcc.dg/compat/vector-1 c_compat_x_tst.o compile
FAIL: gcc.dg/compat/vector-1 c_compat_y_tst.o compile
UNRESOLVED: gcc.dg/compat/vector-1 c_compat_x_tst.o-c_compat_y_tst.o link
UNRESOLVED: gcc.dg/compat/vector-1 c_compat_x_tst.o-c_compat_y_tst.o 
execute
FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o compile
FAIL: gcc.dg/compat/vector-2 c_compat_y_tst.o compile
UNRESOLVED: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o link
UNRESOLVED: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o 
execute

There are problems with SPE argument passing.

Paolo



-- 


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

[Bug tree-optimization/17928] New: ICE involving 'goto' to jump into loop

[bryner at brianryner dot com]

The testcase I'm going to attach gives an ICE when you compile like this:

gcc -Os -c -o gcc-prdtoa-testcase.o gcc-prdtoa-testcase.c

problem occurs with -Os but _not_ with -O0, -O1, -O2, or -O3.  Looks like some
sort of infinite recursion with analyze_scaler_evolution().  This was as reduced
as I could get the testcase.

compiler version:
$ gcc -v
Reading specs from /usr/gcc4/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/usr/gcc4 --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++
--disable-libgcj
Thread model: posix
gcc version 4.0.0 20041011 (experimental)

-- 
   Summary: ICE involving 'goto' to jump into loop
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bryner at brianryner 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=17928

[Bug tree-optimization/17928] ICE involving 'goto' to jump into loop

[bryner at brianryner dot com]

--- Additional Comments From bryner at brianryner dot com  2004-10-11 07:54 ---
Created an attachment (id=7321)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7321&action=view)
testcase


-- 


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

[Bug fortran/17675] Alignment constraints not honored in EQUIVALENCE

[c dot christian dot joensson at comhem dot se]

-- 
   What|Removed |Added

 CC||christian at j-son dot org


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

[Bug c/17301] ICE on wrong usage of __builtin_stdarg_start

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 08:52 
---
Joseph, your fix is only a partial one. We still ICE if no argument at all
is passed to __builtin_stdarg_start:

=
void foo (char *format, ...)
{
  __builtin_stdarg_start ();
}
=

bug.c: In function `foo':
bug.c:3: error: too few arguments to function `__builtin_stdarg_start'
bug.c:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/17929] New: [3.4/4.0 regresssion] ICE with qualified name in template specialization

[reichelt at gcc dot gnu dot org]

Mark, your patch for PR 17393
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00485.html
breaks the test testsuite/g++.dg/parse/qualified2.C


namespace Glib {
  template  class Value {};
  template <> class Glib::Value {}; // { dg-error "" }
}


qualified2.C:3: error: extra qualification ignored
qualified2.C:3: error: explicit specialization of non-template 'Glib::'
qualified2.C:3: error: abstract declarator 'Glib::' used as
declaration
qualified2.C:3: internal compiler error: tree check: expected class
'declaration', have 'exceptional' (error_mark) in finish_anon_union, at
/cp/decl2.c:1190
Please submit a full bug report, [etc.]

Could you please have a look?

-- 
   Summary: [3.4/4.0 regresssion] ICE with qualified name in
template specialization
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, ice-checking
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com


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

[Bug c++/17929] [3.4/4.0 regresssion] ICE with qualified name in template specialization

[reichelt at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.4.3


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

[Bug java/17845] can't build GNU Classpath

[aph at redhat dot com]

--- Additional Comments From aph at redhat dot com  2004-10-11 09:11 ---
Subject:  can't build GNU Classpath

I think I'm going to have to give up on this bug.  If I can't
duplicate the problem myself and you can't duplicate the propblem on
any machine to which I have access there's nothing that I can do.


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-11 09:28 
---
(In reply to comment #4)

> I disagree with the notion that it is just a diagnostic related issue;
> because it comes with a semantics part.  Let's not not disguise a
> language extension under the name of diagnostic improvement.  
> It helps nobody. 

I am not trying to, really.

In my view, the compilation unit will produce exactly the same object file, 
whether attribute(reimpl) is implemented or not, used or not. The only 
difference is that with attribute(reimpl) we might emit a warning iff the 
method does not override another virtual method in the base class.

Why do you think there is a semantics part? Maybe I do not get it.

-- 


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

[Bug target/17767] [4.0 Regression] MMX intrinsics cause internal compiler error

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 09:42 
---
Roger, your patch for PR 17853
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00486.html
fixed PR17767 on the 3.4 branch. The problem on mainline remains, though.

Could you please have a look?


-- 
   What|Removed |Added

 CC||sayle at gcc dot gnu dot org
Summary|[3.4/4.0 Regression] MMX|[4.0 Regression] MMX
   |intrinsics cause internal   |intrinsics cause internal
   |compiler error  |compiler error
   Target Milestone|3.4.3   |4.0.0


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

[Bug tree-optimization/17928] ICE involving 'goto' to jump into loop

[reichelt at gcc dot gnu dot org]

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


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 10:28 
---
*** Bug 17928 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||bryner at brianryner dot com


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

[Bug rtl-optimization/14110] altivec code misoptimized with any -O

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-11 10:45 
---
Lu Zero, I'm revisiting this bug report. The testcase you provided cannot be 
executed to check for the miscompilation, which makes it very difficult for us 
to check for the problem.

Would you please provide a testcase with a main() invoking idc_add_altivec() 
with some valid parameters, and aborting if the result is incorrect (assuming 
it does not crash right way because of the miscompilation)?

Thanks

-- 
   What|Removed |Added

 CC||giovannibajo at libero dot
   ||it
 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/17755] Can't compile djgpp cross-compiler

[pavenis at latnet dot lv]

--- Additional Comments From pavenis at latnet dot lv  2004-10-11 10:53 ---
One more trap:  
 
DJGPP includes are expected to be at $prefix/$target/sys-include.  
Symbolic link of $prefix/$target/include to it should suffice. 
 
Verified that absence of such directory causes described problem. 
 

-- 


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

[Bug middle-end/14192] Restrict pointers don't help

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-11 10:56 
---
Zack, do you confirm that the semantics of restrict (in C99 and/or GNU C) allow 
us to schedule the load before the store even if there is only one restrict 
pointer? Otherwise, this bug report is invalid.

-- 
   What|Removed |Added

 CC||zack at gcc dot gnu dot org,
   ||giovannibajo at libero dot
   ||it


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

[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-11 10:57 
---
Daniel, Richard, is still bug still actual? Can we move this to confirmed 
status if you agree on the bug? Thanks.

-- 


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

[Bug target/14300] -pthread doesn't define _REENTRANT in preprocessor on alpha-linux

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-11 10:58 
---
Confirmed. There is some discussion going on about this.

-- 
   What|Removed |Added

  BugsThisDependsOn||10865
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 10:58:39
   date||


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

[Bug target/14330] using -O3 causes a core whereas -O2 and under work

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-11 11:09 
---
Created an attachment (id=7322)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7322&action=view)
Testcase

Attacched the testcase. In future, please do not copy & paste large testcases
into a comment, but just attacch them.

-- 


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

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2004-10-11 11:39 ---
Carlo, I realise the text (which I've committed btw) is quite Boost-specific,
that's because
1) Boost is the only code I use which is affected by this PR (selfish, I know)
2) Boost is the only library for which a simple workaround is given on this PR.



-- 


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

[Bug middle-end/17908] [4.0 Regression] ICE: tree check: expected function_decl, have continue_stmt in c_expand_body, at /c-decl.c:6328

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 11:47 
---
Here's a reduced testcase:

===
int foo()
{
unsigned char c;
switch ((int)c)
{
  case -1:
  case 0:
  case 4:
  case 5:
  case 42:
return 0;
}
}
===

parse.i: In function 'foo':
parse.i:13: internal compiler error: tree check: expected function_decl, have
error_mark in c_expand_body, at /c-decl.c:6334
Please submit a full bug report, [etc.]

If I replace the 42 with 39 for example, I get a segfault instead.

This might be related to PR 17657.


-- 
   What|Removed |Added

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


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

[Bug c/17301] ICE on wrong usage of __builtin_stdarg_start

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|REOPENED|NEW
   Target Milestone|4.0.0   |---


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

[Bug c++/17929] [3.4/4.0 regresssion] ICE with qualified name in template specialization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 11:52 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.4.3 4.0.0
  Known to work||3.4.2
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 11:52:15
   date||


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

[Bug rtl-optimization/6585] Redundant store/load instruction pairs on ix86

[bruno at clisp dot org]

--- Additional Comments From bruno at clisp dot org  2004-10-11 11:55 ---
This result is even better: shorter than the previous ones, and there are 
no useless moves between registers any more. 
 
However, there are more useless moves from register to stack slot and back 
from stack slot to register. They could be eliminated. 
 
Commented listing: 
 
mul: 
subl$20, %esp 
movl32(%esp), %ecx  b0 
movl24(%esp), %eax  a0 
movl%ebx, 8(%esp)   ; save %ebx 
movl36(%esp), %ebx  b1 
movl%edi, 12(%esp)  ; save %edi 
movl24(%esp), %edi  a0 
movl%ebp, 16(%esp)  ; save %ebp 
mull%ecx%edx:%eax := a0*b0 
imull   28(%esp), %ecx  a1*b0 
imull   %ebx, %edi  a0*b1 
movl8(%esp), %ebx   ; restore %ebx 
movl%edx, %ebp  hi 
movl%eax, (%esp)USELESS! 
addl%edi, %ebp  hi+a0*b1 
movl(%esp), %eaxUSELESS! 
leal(%ebp,%ecx), %ecx   hi+a0*b1+a1*b0  COULD GO INTO %edx 
DIRECTLY 
movl12(%esp), %edi  ; restore %edi 
movl%ecx, 4(%esp)   USELESS! 
movl16(%esp), %ebp  ; restore %ebp 
movl4(%esp), %edx   USELESS! 
addl$20, %esp 
ret 
 

-- 


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

[Bug target/14330] using -O3 causes a core whereas -O2 and under work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 11:55 
---
I think this is case where asm __volatile__ can be moved around (not scheduled though).

-- 


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

[Bug libstdc++/15466] libstd++ build error for sh-hms

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 12:00 
---
Closing as works for me as there was no feedback in 3 months (T-9 days) and it worked 
for Benjamin 
Kosnik.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug fortran/17930] New: -mfpmath=sse creates illegal code (movapd with misaligned argument)

[gcc-bugzilla at gcc dot gnu dot org]

Using the option "-mfpmath=sse" in g77 (to use SSE instructions for
floating point arithmetic) can create illegal code, or at least
code that is called with illegal arguments. Specifically, I have a
test case where a "movapd" instruction is called with a second argument
that is not 16-byte-aligned, causing a segmentation violation.
Details below in section "How-To-Repeat".
This bug is probably related to the one with ID 14776. However, that bug
was reported for a different target, has been open for more than six
months, and is still unassigned, so I consider it worthwile reporting
this on my own.

Environment:
System: Linux pc-lenz 2.4.27-rc5-tc2 #2 SMP Fri Aug 20 15:42:48 CEST 2004 i686 
GNU/Linux
Architecture: i686

host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared 
--with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --disable-werror 
i486-linux

How-To-Repeat:
This is the Fortran77 source of a program that shows the problem:

== gccbug.f ==
  program test

  implicit none

  integern,error,i,j
  real*8 tol
  complex*16 work(5,5,2)

  n=5
  do j=1,n
 do i=1,n
if (i.eq.j) then
   work(i,j,1)=dcmplx(1.0d0,0.0d0)
else
   work(i,j,1)=dcmplx(0.0d0,0.0d0)
endif
 enddo
  enddo
  tol=1.0d-8

  call matinvzhp(work(1,1,2),work(1,1,1),n,n,tol,error)

  write (*,*) 'Error=',error

  return
  end


C---
C   CHOLESKYZHP
C
C Decomposites a complex hermitian (H), positive definite (P) matrix
C A into a product of a left lower triangular matrix L and its adjoint,
C i. e. A = L L^dagger where L_ij = 0 for j > i and L_ii is real and
C positive. All calculations are performed with double precision (Z).
C
C Input parameters:
C   a: The matrix to be decomposited (a(i,j) is needed for j <= i
C  only).
C   dim:   The number of allocated rows (and columns) of "a".
C   n: The number of used rows (and columns) of "a".
C   tol:   A (relative) tolerance for the check wether "a" is hermitian
C  and positive definite.
C
C Output parameters:
C   a: The left lower triangular matrix L. (The part of "a" right of
C  the diagonal still contains the corresponding part of A.)
C   error: An error flag having the following meaning:
C  0: Everything was o. k.
C  1: The matrix is not hermitian and positive definite.
C---

  subroutine choleskyzhp (a,dim,n,tol,error)

  implicit none

  integerdim,n,error,i,j,k
  real*8 tol,y,tmp
  complex*16 a(dim,dim),x

  error = 0
  do j = 1,n
 do i = j,n
x = a(i,j)
do k = 1,j-1
   x = x-a(i,k)*dconjg(a(j,k))
enddo
if (i .eq. j) then
   tmp=dble(x)
   if (dabs(dimag(x)) .gt. tol*tmp) then
  error = 1
  return
   else
C write (*,*) tmp
  tmp=dsqrt(tmp)
  a(i,j) = dcmplx(tmp)
  y = 1.0d0/tmp
   endif
else
   a(i,j) = x*y
endif
 enddo
  enddo

  return
  end

C---
C   MATINVZHP
C
C Inverts a double precision complex (Z), Hermitian (H), and positive
C definite (P) matrix A employing a Cholesky-decomposition of A.
C
C Input parameters:
C   a: The matrix to be inverted (a(i,j) is needed for j <= i only).
C   dim:   The number of allocated rows (and columns) of "a".
C   n: The number of used rows (and columns) of "a".
C   tol:   A (relative) tolerance for the check whether "a" is Hermitian
C  and positive definite.
C Output parameters:
C   b: The inverse of "a".
C   a: The matrix "a" is overwritten.
C   error: An error flag having the following meaning:
C  0: Everything was o. k.
C  1: The matrix "a" is not hermitian and positive definite.
C Remarks:
C   Library routine "choleskyzhp" is used.
C---

  subroutine matinvzhp (b,a,dim,n,tol,error)

  implicit none

  complex*16 zeroz,onez
  parameter (zeroz = (0.0d0,0.0d0),onez = (1.0d0,0.0d0))

  integerdim,n,erro

[Bug fortran/17930] -mfpmath=sse creates illegal code (movapd with misaligned argument)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 12:03 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/14776] -mfpmath=sse causes movapd from non-16-byte aligned address

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||Frank dot Otto at tc dot pci
   ||dot uni-heidelberg dot de


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

[Bug target/14776] -mfpmath=sse causes movapd from non-16-byte aligned address

[Frank dot Otto at tc dot pci dot uni-heidelberg dot de]

--- Additional Comments From Frank dot Otto at tc dot pci dot uni-heidelberg dot 
de  2004-10-11 12:09 ---
(In reply to comment #13)
> *** Bug 17930 has been marked as a duplicate of this bug. ***

However, Bug 17930 might still be worth looking at, since it
includes a fortran source file with which you can easily reproduce
this bug, even on non-cygwin targets.

-- 


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

[Bug libstdc++/17922] [3.3/3.4/4.0 regression] Spurious warnings about std::ios_base::seekdir

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 12:21 
---
Confirmed. In fact we have:

  enum _Ios_Seekdir { _S_ios_seekdir_end = 1L << 16 };

  class ios_base
  {
typedef _Ios_Seekdir seekdir;
static const seekdir beg = seekdir(0);
static const seekdir cur = seekdir(1);
static const seekdir end = seekdir(2);
// more stuff ...
  };

The problem exists at least since gcc 3.1. In fact the code was already
there in gcc 3.0, but the compiler didn't complain about it.

In 2.95.3 we had:

enum seek_dir { beg, cur, end};

Therefore I rate this as regression.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic, monitored
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 12:21:52
   date||
Summary|Spurious warnings   |[3.3/3.4/4.0 regression]
   ||Spurious warnings about
   ||std::ios_base::seekdir
   Target Milestone|--- |3.4.3


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

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2004-10-11 12:22 ---
I've been thinking about this PR, probably too much. I assume my concerns are
unfounded, or we'd have noticed bigger problems by now, but here goes:

The change to gthr-posix.h means that if GCC is configured with thread-support
on Tru64 then it _always_ compiles thread-safe programs, even when -pthread
is not used. The only way to prevent that is to configure with --disable-threads.
Carlo said in comment #25 that this means even single-threaded apps will use
slower, reentrant versions of libs. For system libs, this is not true,
because if -pthread is not given then the reentrant libs won't be linked to,
even though _REENTRANT was defined. Is it even well-formed to define
_REENTRANT and include  but _not_ link to the reentrant libs?

Tru64's  (at least, the fixincluded version) says:

 * You should always define _REENTRANT on the command line, usually by using
 * "cc -pthread" or "cxx -pthread", to be sure that it will be available for
 * all header files.

This recommendation is not followed by gthr-posix.h, which defines _REENTRANT
only before including . Not all libstdc++ headers include
gthr-posix.h, so _REENTRANT won't always be defined e.g.  doesn't
include gthr-posix.h, so in this code:

  #include 
  #include 
  #include 

_REENTANT will not be defined when unistd.h is included. The above comment
from Tru64's pthread.h is followed by "#include " which will have no
effect if that file was already included before _REENTRANT was defined.

Rainer's proposal to put _REENTRANT in os_defines.h will ensure that
_REENTRANT is always defined, but it won't get around the issue of including
thread-safe definitions but not linking to them (but maybe that's a non-issue).

Would it be possible to only include  if _REENTRANT is defined,
and include some  otherwise, which just has dummy decls for
the pthread_xxx() functions needed by gthreads? That way whether reentrant
code is used would depend on whether -pthread was used, as is intended.

I have very litle experience with either MT or Tru64, so probably haven't got
this analysis right, I'm just trying to understand the issues better.


-- 


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

[Bug other/15548] libgfortran in wrong CVS module, breaks build

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 12:50 
---
gcc/fixinc does not exist on the mainline any more (as it was moved to the toplevel) 
so this is not a 
mainline problem, only a CVS problem so I am removing the target milestone and the 
regression 
marker in the summary.

-- 
   What|Removed |Added

Summary|[4.0 Regression] libgfortran|libgfortran in wrong CVS
   |in wrong CVS module, breaks |module, breaks build
   |build   |
   Target Milestone|4.0.0   |---


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-11 12:54 ---
I concur with Giovanni: this is a case very much like the format 
checking for printf and attribute sentinel. If you simply remove 
the attribute statement, then the generated code is exactly the 
same in all cases, the attribute is there only to enable the compiler 
to emit more warnings. 
 
W. 

-- 


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

[Bug c++/17929] [3.4/4.0 regresssion] ICE with qualified name in template specialization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 13:21 
---
Patch here: , Mine.

-- 
   What|Removed |Added

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


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

[Bug middle-end/17908] [4.0 Regression] ICE: tree check: expected function_decl, have continue_stmt in c_expand_body, at /c-decl.c:6328

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 13:45 
---
Note that I can reproduce it with a full bootstrap compiler but not with just stage 1 
so something is 
causing wrong code somewhere.

-- 
   What|Removed |Added

   Severity|normal  |critical
   Keywords||wrong-code


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 13:49 
---
Andreas, yes please for PPC and/or x86.

It might be we are miscompiling GCC :(.

-- 


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

[Bug rtl-optimization/17931] New: andl and testb are not combined

[kazu at cs dot umass dot edu]

Consider:

struct flags {
  unsigned f0 : 1;
  unsigned f1 : 1;
};

_Bool
foo (struct flags *p)
{
  if (p->f0)
return 1;

  return p->f1;
}

With "cc1 -O2 -fomit-frame-pointer", I get

foo:
movl4(%esp), %eax
movb(%eax), %dl
movb%dl, %al
andl$1, %eax
testb   %al, %al
jne .L7
xorl%eax, %eax
testb   $2, %dl
setne   %al
ret
.p2align 2,,3
.L7:
movl$1, %eax
ret

Note that andl and testb are not combined to "testb $1, %al".
If they were combined, we would not destroy %eax,
so we would not need to make a copy of %al for a later use.

With -march=pentium4 or -march=athlon-xp, I get a similar result.

-- 
   Summary: andl and testb are not combined
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/17931] andl and testb are not combined

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-10-11 13:54 ---
Actually, we don't need "movl $1, %eax" at the end, either.


-- 


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

[Bug rtl-optimization/17931] andl and testb are not combined

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 14:01 
---
Confirmed, combine does not simplify:
(insn 14 13 15 0 (parallel [
(set (reg:QI 64)
(and:QI (reg:QI 63)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 206 {*andqi_1} (insn_list:REG_DEP_TRUE 13 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

(insn 15 14 16 0 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 64)
(const_int 0 [0x0]))) 6 {*cmpqi_ccno_1} (insn_list:REG_DEP_TRUE 14 (nil))
(expr_list:REG_DEAD (reg:QI 64)
(nil)))

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 14:01:46
   date||


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

[Bug rtl-optimization/17931] andl and testb are not combined

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 14:06 
---
Note PPC's resulting asm is so much better:
lwz r3,0(r3)
li r0,1
cmpwi cr7,r3,0
blt- cr7,L4
rlwinm r0,r3,2,31,31
L4:
mr r3,r0
blr

But can be improved still down to (but that is a register allocator problem):
lwz r0,0(r3)
cmpwi cr7,r0,0
li r3,1
bltlr- cr7
rlwinm r3,r0,2,31,31
blr

-- 


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

[Bug c/17932] New: gcc-3.4.2 fails to compile glibc-2.3.3

[ansgar dot radermacher at cea dot fr]

When compiling glibc-2.3.3 (configured from a new subdir "obj" using simply
../configure --enable-add-ons), I get the following error message in glibc
subdirectory "elf". The problems seems to be a gcc bug, since gcc-3.3.4 compiles
fine (and since I could not really see why the types should conflict).

Ansgar

-

gcc -v
Reading specs from /local/software/gcc/3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ../configure --prefix=/local/software/gcc/3.4.2
Thread model: posix
gcc version 3.4.2

-

make

make[2]: Entering directory `/tmp/glibc-2.3.3/elf'
gcc dl-runtime.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes
-Wwrite-strings -g -mpreferred-stack-boundary=2  -fexceptions
-fasynchronous-unwind-tables   -I../include -I. -I/tmp/glibc-2.3.3/obj/elf -I..
-I../libio  -I/tmp/glibc-2.3.3/obj -I../sysdeps/i386/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/i386
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/i386/i686
-I../linuxthreads/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386
-I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686
-I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I
/lib/modules/2.4.25/build/include -D_LIBC_REENTRANT -include
../include/libc-symbols.h   -o /tmp/glibc-2.3.3/obj/elf/dl-runtime.o -MD -MP
-MF /tmp/glibc-2.3.3/obj/elf/dl-runtime.o.dt
dl-runtime.c:57: error: conflicting types for 'fixup'
../sysdeps/i386/dl-machine.h:158: error: previous declaration of 'fixup' was here
dl-runtime.c:57: error: conflicting types for 'fixup'
../sysdeps/i386/dl-machine.h:158: error: previous declaration of 'fixup' was here
dl-runtime.c:142: error: conflicting types for 'profile_fixup'
../sysdeps/i386/dl-machine.h:161: error: previous declaration of 'profile_fixup'
was here
dl-runtime.c:142: error: conflicting types for 'profile_fixup'
../sysdeps/i386/dl-machine.h:161: error: previous declaration of 'profile_fixup'
was here
../sysdeps/i386/dl-machine.h:158: warning: 'fixup' declared `static' but never
defined
../sysdeps/i386/dl-machine.h:161: warning: 'profile_fixup' declared `static' but
never defined

-- 
   Summary: gcc-3.4.2 fails to compile glibc-2.3.3
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ansgar dot radermacher at cea dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: gcc-3.4.2
  GCC host triplet: Linux 2.4.27


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

[Bug rtl-optimization/17931] [4.0 Regresion] andl and testb are not combined

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 14:12 
---
This is a regression from 2.95.3:
movl 4(%esp),%eax
testb $1,(%eax)
jne .L3
movb (%eax),%al
shrb $1,%al
andl $1,%eax
ret
.p2align 4,,7
.L3:
movl $1,%eax
ret
And 3.0.4:
foo:
movl4(%esp), %eax
testb   $1, (%eax)
je  .L2
movl$1, %eax
ret
.p2align 4,,7
.L2:
movzbl  (%eax), %eax
shrb%al
andl$1, %eax
ret
And 3.2.3,3.3.3, and 3.4.0:
foo:
movl4(%esp), %eax
movl$1, %edx
movzbl  (%eax), %eax
testb   $1, %al
jne .L1
shrb%al
movl%eax, %edx
andl$1, %edx
.L1:
movl%edx, %eax
ret
.size   foo, .-foo
.section.note.GNU-stack,"",@progbits
.ident  "GCC: (GNU) 3.4.0"

-- 
   What|Removed |Added

   Severity|enhancement |minor
  Known to fail||4.0.0
  Known to work||3.3.3 3.0.4 2.95.3 3.4.0
Summary|andl and testb are not  |[4.0 Regresion] andl and
   |combined|testb are not combined
   Target Milestone|--- |4.0.0


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

[Bug c/17932] gcc-3.4.2 fails to compile glibc-2.3.3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 14:14 
---
See  for why this was changed.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/15095] [3.4/4.0 Regression] gcc-3.4.0 fails to compile gmp-4.1.2

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||ansgar dot radermacher at
   ||cea dot fr


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

[Bug c++/17929] [4.0 regresssion] ICE with qualified name in template specialization

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[3.4/4.0 regresssion] ICE   |[4.0 regresssion] ICE with
   |with qualified name in  |qualified name in template
   |template specialization |specialization
   Target Milestone|3.4.3   |4.0.0


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

[Bug rtl-optimization/17931] [4.0 Regression] andl and testb are not combined

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-10-11 14:47 ---
The combiner does try to combine andl and testb,
but the suggested combined insn is rejected by combine_validate_cost.

The cost of "andl $1, %eax" is 4.
The cost of "testb %al, %al" is 4.
So the original total cost is 8.

The cost of the combined insn, shown below, is 12.

(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (subreg:SI (reg:QI 63) 0)
(const_int 1 [0x1])
(const_int 0 [0x0]))
(const_int 0 [0x0])))

We need to teach ix86_rtx_cost to treat
(compare (zero_extract X (const_1) ...)) the same as and.


-- 


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

[Bug libstdc++/17922] [3.3/3.4/4.0 regression] Spurious warnings about std::ios_base::seekdir

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-11 14:47 ---
By the way, the other flags (e.g. openmode, iostate, fmflags) are affected by the
same problem. Unfortunately, I'm not sure we can fix this within the 3.4/4.0 ABI.

-- 


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

[Bug c++/17929] [3.4/4.0 regresssion] ICE with qualified name in template specialization

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 14:53 
---
Andrew, 3.4 branch is also affected, since Mark also patched the 3.4 branch:
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00488.html

See for example
http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg00524.html


-- 
   What|Removed |Added

Summary|[4.0 regresssion] ICE with  |[3.4/4.0 regresssion] ICE
   |qualified name in template  |with qualified name in
   |specialization  |template specialization
   Target Milestone|4.0.0   |3.4.3


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

[Bug c++/17929] [4.0 regresssion] ICE with qualified name in template specialization

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 14:57 
---
Sorry, Andrew, I didn't see Mark's reply to your patch.
It would have helped, if you said, why you changed the milestone etc.


-- 
   What|Removed |Added

Summary|[3.4/4.0 regresssion] ICE   |[4.0 regresssion] ICE with
   |with qualified name in  |qualified name in template
   |template specialization |specialization
   Target Milestone|3.4.3   |4.0.0


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

[Bug c++/17929] [4.0 regresssion] ICE with qualified name in template specialization

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 14:58 
---
Fixed on the 3.4 branch by
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00909.html

-- 


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

[Bug libstdc++/17864] [4.0 Regression] deallocate_global

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-10-11 15:03 ---
Failures fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/17929] [4.0 regresssion] ICE with qualified name in template specialization

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2004-10-11 15:05 ---
Subject: Re:  [4.0 regresssion] ICE with qualified name in
 template specialization

reichelt at gcc dot gnu dot org wrote:

>--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 14:58 
>---
>Fixed on the 3.4 branch by
>http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00909.html
>  
>
I'll bring that patch over to 4.0 shortly.  The tests passed with all of 
my changes on my copy of mainline; apparently, some other change to 
mainline, after my tests ran, interacted poorly with my patches.  I'm 
rebuilding now to make sure I can see the mainline failure; then I'll 
apply my patch.



-- 


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

[Bug middle-end/17933] New: [4.0 Regression] ICE: in schedule_insns, at /sched-rgn.c:2555

[danglin at gcc dot gnu dot org]

The following regression occurs in the objc testsuite:

Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc -B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc/execute/class_self-2.m  -w  -O2  -
I/test/gnu/gcc-3.3/gcc/gcc/testsuite/../../libobjc -L/test/gnu/gcc-3.3/objdir/hp
pa64-hp-hpux11.11/./libobjc/.libs  -lobjc -lm   -o /test/gnu/gcc-3.3/objdir/gcc/
testsuite/class_self-2.x2(timeout = 300)
/test/gnu/gcc-3.3/gcc/gcc/testsuite/objc/execute/class_self-2.m: In function '+[
TestClass test]':
/test/gnu/gcc-3.3/gcc/gcc/testsuite/objc/execute/class_self-2.m:58: internal com
piler error: in schedule_insns, at /sched-rgn.c:2555

-- 
   Summary: [4.0 Regression] ICE: in schedule_insns, at /sched-
rgn.c:2555
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
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: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-10-11 15:28 ---
(In reply to comment #6) 
> Andreas, yes please for PPC and/or x86. 
>  
> It might be we are miscompiling GCC :(. 
 
Here's the actual call on 32-bit ppc: 
 
# gcc -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE_DATA_DIR=\""/opt/gnome/share"\" 
-DPACKAGE_LOCALE_DIR=\""/opt/gnome/share/locale"\" -DXTHREADS -D_REENTRANT 
-DXUSE_MTSAFE_API -DORBIT2=1 -pthread -I/usr/include/libart-2.0 
-I/usr/include/libxml2 -I/opt/gnome/include/panel-2.0 
-I/opt/gnome/include/gtk-2.0 -I/opt/gnome/include/libgnomeui-2.0 
-I/opt/gnome/include/libbonoboui-2.0 -I/opt/gnome/lib/gtk-2.0/include 
-I/usr/X11R6/include -I/opt/gnome/include/atk-1.0 
-I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/freetype2/config -I/opt/gnome/include/glib-2.0 
-I/opt/gnome/lib/glib-2.0/include -I/opt/gnome/include/libgnome-2.0 
-I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gconf/2 
-I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 
-I/opt/gnome/include/gnome-vfs-2.0 -I/opt/gnome/lib/gnome-vfs-2.0/include 
-I/opt/gnome/include/bonobo-activation-2.0  -g -O2 -MT support.o -MD -MP 
-MF".deps/support.Tpo"   -c -o support.o support.c -v -save-temps 
Reading specs from /usr/lib/gcc/powerpc-suse-linux/4.0.0/specs 
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local--infodir=/usr/share/info --mandir=/usr/share/man 
--libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java 
--enable-checking --with-slibdir=/lib --with-system-zlib --enable-shared 
--enable-__cxa_atexit powerpc-suse-linux 
Thread model: posix 
gcc version 4.0.0 20041010 (experimental) (SUSE Linux) 
 /usr/lib/gcc/powerpc-suse-linux/4.0.0/cc1 -E -quiet -v -I. -I. -I.. 
-I/usr/include/libart-2.0 -I/usr/include/libxml2 -I/opt/gnome/include/panel-2.0 
-I/opt/gnome/include/gtk-2.0 -I/opt/gnome/include/libgnomeui-2.0 
-I/opt/gnome/include/libbonoboui-2.0 -I/opt/gnome/lib/gtk-2.0/include 
-I/usr/X11R6/include -I/opt/gnome/include/atk-1.0 
-I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/freetype2/config -I/opt/gnome/include/glib-2.0 
-I/opt/gnome/lib/glib-2.0/include -I/opt/gnome/include/libgnome-2.0 
-I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gconf/2 
-I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 
-I/opt/gnome/include/gnome-vfs-2.0 -I/opt/gnome/lib/gnome-vfs-2.0/include 
-I/opt/gnome/include/bonobo-activation-2.0 -MD support.d -MF .deps/support.Tpo 
-MP -MT support.o -MQ support.o -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix 
-D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix 
-D_REENTRANT -DHAVE_CONFIG_H -DPACKAGE_DATA_DIR="/opt/gnome/share" 
-DPACKAGE_LOCALE_DIR="/opt/gnome/share/locale" -DXTHREADS -D_REENTRANT 
-DXUSE_MTSAFE_API -DORBIT2=1 support.c -fworking-directory -O2 -fpch-preprocess 
-o support.i 
ignoring duplicate directory "." 
ignoring nonexistent directory "/usr/include/freetype2/config" 
#include "..." search starts here: 
#include <...> search starts here: 
 . 
 .. 
 /usr/include/libart-2.0 
 /usr/include/libxml2 
 /opt/gnome/include/panel-2.0 
 /opt/gnome/include/gtk-2.0 
 /opt/gnome/include/libgnomeui-2.0 
 /opt/gnome/include/libbonoboui-2.0 
 /opt/gnome/lib/gtk-2.0/include 
 /usr/X11R6/include 
 /opt/gnome/include/atk-1.0 
 /opt/gnome/include/pango-1.0 
 /usr/include/freetype2 
 /opt/gnome/include/glib-2.0 
 /opt/gnome/lib/glib-2.0/include 
 /opt/gnome/include/libgnome-2.0 
 /opt/gnome/include/libgnomecanvas-2.0 
 /opt/gnome/include/gconf/2 
 /opt/gnome/include/orbit-2.0 
 /opt/gnome/include/libbonobo-2.0 
 /opt/gnome/include/gnome-vfs-2.0 
 /opt/gnome/lib/gnome-vfs-2.0/include 
 /opt/gnome/include/bonobo-activation-2.0 
 /usr/local/include 
 /usr/lib/gcc/powerpc-suse-linux/4.0.0/include 
 /usr/lib/gcc/powerpc-suse-linux/4.0.0/../../../../powerpc-suse-linux/include 
 /usr/include 
End of search list. 
 /usr/lib/gcc/powerpc-suse-linux/4.0.0/cc1 -fpreprocessed support.i -quiet 
-dumpbase support.c -auxbase-strip support.o -g -O2 -version -o support.s 
GNU C version 4.0.0 20041010 (experimental) (SUSE Linux) (powerpc-suse-linux) 
compiled by GNU C version 4.0.0 20041010 (experimental) (SUSE Linux). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
support.c: In function 'tsc_launch_remote': 
support.c:198: internal compiler error: in replace_immediate_uses, 
at /tree-ssa.c:1056 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See http://www.suse.de/feedback> for instructions. 
 
I'll attach support.i as bzip2 compressed file. 
 

-- 


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-10-11 15:29 ---
Created an attachment (id=7325)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7325&action=view)
Preprocessed file for Linux/PPC


-- 


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

[Bug rtl-optimization/17931] [4.0 Regression] andl and testb are not combined

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-10-11 15:32 ---
I'll be testing a patch shortly.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kazu at cs dot umass dot edu
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 15:47 
---
Here's a reduced testcase that fails with "-O" on i686-pc-linux-gnu:


int sprintf (char *s, const char *format, ...);

int foo(int i, int j)
{
   char *buf, *str;

   if (i)
 str = "";
   else if (j)
 str = "";
   else
 return 1;

   sprintf(buf, str);
   return 0;
}



-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||monitored
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 15:47:03
   date||


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

[Bug fortran/17927] Math error in simple divide operation

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-10-11 15:54 ---
gfortran uses its own constant folder, which uses the mpfr library. Apparently
the precision is too low for double precision. Output from -fdump-parse-tree
includes:
  ASSIGN big 6.6686534882e-1_8
So it's indeed the frontend's fault.

-- 


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

[Bug rtl-optimization/17933] [4.0 Regression] ICE: in schedule_insns, at /sched-rgn.c:2555

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 15:55 
---
  /* Verify the counts of basic block notes in single the basic block
 regions.  */

Hmm.

-- 
   What|Removed |Added

  Component|middle-end  |rtl-optimization
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.0.0


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

[Bug fortran/17927] Math error in simple divide operation

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-10-11 16:00 ---
Actually, looking at this again, gfortran's behavior is correct.

If you had written
 big = 2.0_8 / 3.0_8
you would have gotten the result you were expecting.

I think, adding a warning would be the best route for "fixing" this problem.

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug rtl-optimization/17933] [4.0 Regression] ICE: in schedule_insns, at /sched-rgn.c:2555

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-10-11 
16:06 ---
Subject: Re:  [4.0 Regression] ICE: in schedule_in

> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11
> 15:55 ---
>   /* Verify the counts of basic block notes in single the basic block
>  regions.  */
> 
> Hmm.

I couldn't understand it either.

deaths_in_region[rgn] = 30
count_or_remove_death_notes (blocks, 0) = 29

Dave


-- 


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

[Bug c/17934] New: gcc produces bad (misaligned?) sse2 code

[terpstra at ito dot tu-darmstadt dot de]

For whatever reason, the attached program, when compiled with the options
gcc-3.4 -msse2 -O0 test.c -o test
will crash. This is not the case if -O2 is specified or -march=i686.

However, I have a larger testcase (the program this came from) which will fail
regardless of optimization flags or -march. It seems that this problem only
happens when gcc is given complicated enough code.

A quick look at it with gdb shows:
Program received signal SIGSEGV, Segmentation fault.
0x080483b0 in _mm_srli_epi32 (__A={51539607552, 51539607564}, __B=31)
at emmintrin.h:1261
1261{
(gdb) up
#1  0x080483e3 in bar (x={4294967297, 4294967297}, y={4294967297, 4294967297})
at test.c:8
8   return _mm_sub_epi32(x, _mm_srli_epi32(y, 31));
(gdb) print &x
$1 = (__v2di *) 0xba00
(gdb) down
#0  0x080483b0 in _mm_srli_epi32 (__A={51539607552, 51539607564}, __B=31)
at emmintrin.h:1261
1261{
(gdb) print &__A
$2 = (__v2di *) 0xb9cc

This looks to me like the alignment has somehow gotten messed up.

-- 
   Summary: gcc produces bad (misaligned?) sse2 code
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terpstra at ito dot tu-darmstadt dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-linux-gnu
  GCC host triplet: i386-linux-gnu
GCC target triplet: i386-linux-gnu


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

[Bug middle-end/17657] [4.0 Regression] ICE in expand_case

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 03:42 
---
The orginal testcase is now fixed by the patch to the C++ front-end.
--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-11 16:11 
---
Subject: Bug 17657

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-11 16:11:37

Modified files:
gcc: ChangeLog stmt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: switch-4.c 

Log message:
PR middle-end/17657
* stmt.c (add_case_node): Add additional type argument.  Declare
as static to match prototype.  Convert the upper and lower bounds
to the specified index type.  Optimize away case ranges/values
that are outside the index type's bounds.  Truncate case ranges
that span the index type's bounds.
(expand_case): Avoid unnessary computation and memory allocation
when index type is error_mark_node.  Pass index_type as required
by change to add_case_node API.  No need to convert case range
bounds to index_type, this is now done by add_case_node.

* gcc.dg/switch-4.c: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5834&r2=2.5835
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stmt.c.diff?cvsroot=gcc&r1=1.397&r2=1.398
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4434&r2=1.4435
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/switch-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/17934] gcc produces bad (misaligned?) sse2 code

[terpstra at ito dot tu-darmstadt dot de]

--- Additional Comments From terpstra at ito dot tu-darmstadt dot de  2004-10-11 
16:13 ---
Created an attachment (id=7326)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7326&action=view)
The program which demonstrates the problem

Here's what I narrowed it down to.
Compile with: gcc-3.4 -msse2 -O0 test.c -o test
./test
Segfault!


-- 


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

[Bug ada/17746] [4.0 Regression] ICE when building the shared Ada RTS

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-11 16:17 
---
The outer record type is a derived type of the inner record type so the
expression  is supposed to be a dereference through a polymorphic access type. 
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=17746

[Bug c/17934] gcc produces bad (misaligned?) sse2 code

[terpstra at ito dot tu-darmstadt dot de]

--- Additional Comments From terpstra at ito dot tu-darmstadt dot de  2004-10-11 
16:17 ---
Oh, and this problem doesn't occure in gcc 3.3.
However, gcc-3.3 ICEs on the larger program.
Since it at least compiles on gcc-3.4, I assume that is a different bug which
got fixed.

-- 


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-11 16:19 
---
Eric, the regression appears with your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg01039.html

Could you please have a look?


-- 
   What|Removed |Added

 CC||echristo at redhat dot com


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

[Bug fortran/17918] gfortran .mod files have unusual entries about private common blocks

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot 
de  2004-10-11 16:25 ---
Subject: Re:  gfortran .mod files have unusual entries
 about private common blocks


[ I've added the bug database to the CC list again, this way this discussion
will be archived somewhere and can be referenced ]

Konstantin Olchanski wrote:
> Tobi, I understand how Fortran (<=77) common blocks work, but your
> desription of Fortran-90+ common blocks puzzles me. Our code is written
> like this:
> 
> foo.cmn:
> common /foo/ blah...
> 
> module a
> include "foo.cmn"
> end module a
> 
> module b
> use a
> include "foo.cmn"
> end module b
> 
> module c
> use b
> include "foo.cmn"
> end module c
> 
> Somewhere between module b and c, the current gfortran becomes
> confused and generates bogus errors about size mismatches between
> common blocks and invalid variables from the common block. Absoft, Intel
> and PathScale compilers accept our code, so I think it is valid Fortran-90.
> gfortran barfs, so I assume it is wrong (in a democratic way).

This is wrong code, the other compilers are wrong. I only have the draft
Fortran 95 standard, but since this restriction also appears in F2K (as
Constraint C590) I'm sure this will also be in the final Fortran 95 standard.
What it says is this (eliding irrelavant stuff, pp22,23):
R550 common-block-object is variable name [ ... ]
...
Constraint: A variable-name shall not be a name made accessible by use
association.

Now, due to your multiple including of the same common line, the same name
reappears again and again in a common block, even though it's use associated.
This is the violation of the standard I was referring to.

Actually, after writing this, and double checking the quote in a book which
reproduces the Fortran 90 standard, I see that Fortran 90 doesn't seem to have
this connstraint. So maybe the other compilers will refuxe it in some kind of
strict mode.

> 
> But I still disblieve you theory that common blocks belogn inside
> a module. In the above example, the one common block should be in which
> module? How will this common block be shared with g77, C and
> C++ compiled code?

No, that's not what I'm saying. The thing about common blocks is that they're
_not_ in modules. We have to record them to know where in memory a variable
will be found -- remember that common storage works differently from other
storage. A common variable is replaced to an offset into a common storage,
which carries the name of the respective common block.

> 
> (read on)
> 
> 
>>Say, if you have
>>module m
>>  common /s/ x, y
>>  private x
>>end module
>>
>>use m
>>common /s/ a, b
>>y = 2.
>>print *,b
>>end
>>
>>This program should print "2.".
>>This is why we need the information about x
>>being in the common block in the main program. (I'm not completely sure if
>>symbols which are in a common may be public, and I will verify this,
>>but you get
>>the point).
> 
> 
> This is not how Fortran compilers traditionally work. They save no information
> about the internal structure of the common block- only the name and size.

Indeed, and we record the size by recording the objects that are stored in the
common block. Common block are layouted way after module files have been
written, and this way the frontend needs no knowledge about how memory is
layout in the backend (well, it needs some knowledge to get equivalences
right, but that's not the point), for instance your common block can look
quite different if derived types are packed or not.

> If you have mismatching definitions of common blocks between source
> files, you may get a linker warning (global "s" size mismatch) (older
> linkers did not complain) and you may see "interesting" effects on variable
> values. Most of the time, these are bugs (that is why most programs define
> common blocks in header files), but I have seen (ugly) code where it is
> done on purpose.

Indeed, but when you put common blocks in a module the compiler can do better.
Please note that in
module m
 common /c/ i, j
 private i
end module

use m
i = 4
end
The variable i set in the main program will be a local variable, not the
variable in the common block, so we get that right.

If we add
 common /c/ x, k
 j = 2
 print *, k
to the main program, the compiler needs to know that j is one storage unit
into the common block, and therefore it needs to know more about the common
block than just its size.

The problem you're seeing is that gfortran is quite strict about the standard,
and about where common blocks are allowed. It is not wrong (at least wrt to
these things, and the bugs I thought I had found yesterday were actually bugs
on my side, so I'm quite confident that we get it right)

If Fortran 90 code like yours is something we'd like to support (I'm guessing
you'd want that :-) we can reopen the bug, mark it enhancement, and maybe add
a comment which only contains the things I said about Fortran 90 above, to
make it easier to see why 

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

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-10-11 16:28 ---
This has been a topic of heated discussion in the past. See the bug I added as a
dependency and the various discussions this had spawned. I think as I always
thought that we're safe from the point of view of the standard to allow integer
ranges [-2**31, 2**31-1], and now that the dust has settled I think a patch for
this can be proposed again.

I'll cook something up these days.

-- 
   What|Removed |Added

  BugsThisDependsOn||13490


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

[Bug fortran/17917] gfortran ICE on "equivalence"

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-10-11 16:37 ---
The most suspicious commits are:
2004-07-10  Tobias Schlueter  <[EMAIL PROTECTED]>
Paul Brook  <[EMAIL PROTECTED]>

PR fortran/13415
* trans-common.c (calculate_length): Remove ...
(get_segment_info): Merge into here.  Save field type.
(build_field): Use saved type.
(create_common, new_condition, new_segment, finish_equivalences):
Use new get_segment_info.
* trans-types.c: Update comment.

2004-07-10  Tobias Schlueter  <[EMAIL PROTECTED]>

* trans-decl.c (gfc_create_module_variable): Nothing to do if
symbol is in common, because we ...
(gfc_generate_module_vars): Call gfc_trans_common.



-- 


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

[Bug rtl-optimization/17935] New: Two consecutive movzbl are generated

[kazu at cs dot umass dot edu]

Consider:

struct flags {
  unsigned f0 : 1;
};

_Bool
bar (struct flags *p, struct flags *q)
{
  return (!p->f0 && !q->f0);
}

With "cc1 -O2 -fomit-frame-pointer -march=i386", I get

bar:
movl4(%esp), %eax
testb   $1, (%eax)
jne .L9
movl8(%esp), %eax
testb   $1, (%eax)
sete%al
movzbl  %al, %eax
movzbl  %al, %eax
ret
.p2align 2,,3
.L9:
xorl%eax, %eax
movzbl  %al, %eax
ret

Note the two consecutive movzbl.  We don't need the second one.

Also note the xorl followed by movzbl.  We don't need the movzbl.

-- 
   Summary: Two consecutive movzbl are generated
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

gfortran says to submit bug report

[Joe Koski]

While attempting to compile the NIST FDS4 code (f90 based) I get the
following error

pcp05454784pcs:~/Codes/Fortran_Compiles/fds_test_compile jakoski$ make
gfortran -c -O3 -ffixed-form mods.f
mods.f:628: internal compiler error: backend decl for module variable
y_f_inlet already exists
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [mods.o] Error 1

No "preprocessed source" appeared when I added -save-temps to the compile
line.

The compiler info is

pcp05454784pcs:~/Codes/Fortran_Compiles/fds_test_compile jakoski$ gfortran
-v
Reading specs from /usr/local/lib/gcc/powerpc-apple-darwin7.5.0/4.0.0/specs
Configured with: ../gcc/configure --enable-threads=posix
--enable-languages=f95 --enable-static --disable-shared
Thread model: posix
gcc version 4.0.0 20041009 (experimental)

I'm running on a dual processor G5 Mac under OS X 10.3.5 with Xcode 1.5
installed.

The source code and make file (for xlf Fortran) are available as downloads
from

http://fire.nist.gov/fds/

Hope this helps your efforts. Let me know if you need more info.

Joe Koski
[EMAIL PROTECTED]

[Bug c++/17936] New: [4.0 regression] Instantiation of specialization rejected

[reichelt at gcc dot gnu dot org]

The following code snippet does not compile any more on mainline:

==
template struct A
{
void foo();
};

template struct A<1, N>
{
void foo();
};

template<> void A<1, 2>::foo();
==

vectors.cc:11: error: prototype for `void A<1, N>::foo() [with int N = 2]' does
not match any in class `A<1, 2>'
vectors.cc:8: error: candidate is: void A<1, N>::foo() [with int N = 2]
vectors.cc:11: error: `void A<1, N>::foo() [with int N = 2]' and `void A<1,
N>::foo() [with int N = 2]' cannot be overloaded
vectors.cc:11: error: prototype for `void A<1, N>::foo() [with int N = 2]' does
not match any in class `A<1, 2>'
vectors.cc:8: error: candidate is: void A<1, N>::foo() [with int N = 2]
vectors.cc:11: error: `void A<1, N>::foo() [with int N = 2]' and `void A<1,
N>::foo() [with int N = 2]' cannot be overloaded

This was caused by Mark's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00316.html

Mark, could you please have a look?

-- 
   Summary: [4.0 regression] Instantiation of specialization
rejected
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: rejects-valid, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: bangerth at dealii dot org,gcc-bugs at gcc dot gnu dot
org,mark at codesourcery dot com
OtherBugsDependingO 17522
 nThis:


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

[Bug tree-optimization/17522] ICE with -tree-vectorize

[reichelt at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||17936


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

[Bug c++/17929] [4.0 regresssion] ICE with qualified name in template specialization

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-11 16:59 
---
Subject: Bug 17929

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-11 16:59:24

Modified files:
gcc/cp : ChangeLog decl2.c 

Log message:
PR c++/17929
* decl2.c (finish_anon_union): Robustify.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4424&r2=1.4425
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.751&r2=1.752



-- 


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

[Bug c++/17929] [4.0 regresssion] ICE with qualified name in template specialization

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-10-11 17:01 
---
Fixed in GCC 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/17657] [4.0 Regression] ICE in expand_case

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:02 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

Re: gfortran says to submit bug report

[Andrew Pinski]

On Oct 11, 2004, at 12:38 PM, Joe Koski wrote:
backend decl for module variable

This is most likely the same as PR 17917.
Thanks,
Andrew Pinski

[Bug c++/17936] [4.0 regression] Instantiation of specialization rejected

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:04 
---
Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 17:04:29
   date||
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/13875] [tree-ssa] missed jump thread optimization on the tree-level

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:08 
---
There are some missed PHI-OPT but that is already fixed on the tcb branch.
there are some missed forward propagation opertunies though (I don't know if they are 
fixed on the tcb 
or not).

-- 


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

[Bug c/17934] gcc produces bad (misaligned?) sse2 code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:09 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||terpstra at ito dot tu-
   ||darmstadt dot de


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

[Bug c/17896] The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:12 
---
Patch here: .
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic, patch
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 17:12:24
   date||


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

[Bug other/17361] [3.3/3.4/4.0 Regression] gcc driver complains about C++ options when assembling

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:13 
---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch
  Known to fail|3.3.3 3.4.0 4.0 |3.3.3 3.4.0 4.0.0


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

[Bug rtl-optimization/14110] altivec code misoptimized with any -O

[lu_zero at gentoo dot org]

--- Additional Comments From lu_zero at gentoo dot org  2004-10-11 17:16 ---
Fixed at least on gcc-3.4.x and in the hammer branch.
gcc-3.3.4 should have other problems (I didn't check yet)

the best way to check about the problem works is just use mplayer or ffplay...

-- 


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

[Bug c++/17936] [4.0 regression] Instantiation of specialization rejected

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/14110] altivec code misoptimized with any -O

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:20 
---
Fixed so closing.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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

[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main

[terpstra at ito dot tu-darmstadt dot de]

--- Additional Comments From terpstra at ito dot tu-darmstadt dot de  2004-10-11 
17:21 ---
My bug #17934 was merged with this one.
However, my test case demonstrates the problem WITHOUT threads.
The same issue appears with a single-threaded application of sufficient complexity.

-- 


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

[Bug c/17934] gcc produces bad (misaligned?) sse2 code

[terpstra at ito dot tu-darmstadt dot de]

--- Additional Comments From terpstra at ito dot tu-darmstadt dot de  2004-10-11 
17:22 ---
This bug does not in any way involve multiple threads.
In my attached test case, gcc starts with an aligned stack and screws up the
alignment by itself.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug libstdc++/17937] New: Critical ~__pool troubles

[pcarlini at suse dot de]

Michael Matz distilled this simple testcase from KDE arts:

#include  
#include  
using namespace std; 
static list modulePath; 
int main() 
{ 
  modulePath.push_back("hallo"); 
  return 0; 
}

The attached valgrind output clearly shows that ~__pool is still not ok,
unfortunately.

-- 
   Summary: Critical ~__pool troubles
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,matz at suse dot de
 GCC build triplet: x86-linux
  GCC host triplet: x86-linux
GCC target triplet: x86-linux


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

[Bug rtl-optimization/17935] [4.0 Regression] Two consecutive movzbl are generated

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:24 
---
Confirmed, this is 4.0 Regression again.
3.4.0 gives:
bar:
movl4(%esp), %eax
xorl%edx, %edx
testb   $1, (%eax)
jne .L2
movl8(%esp), %ecx
testb   $1, (%ecx)
jne .L2
movb$1, %dl
.p2align 2,,3
.L2:
movzbl  %dl, %eax
ret

-- 
   What|Removed |Added

   Severity|enhancement |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0
  Known to work||3.4.0
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 17:24:44
   date||
Summary|Two consecutive movzbl are  |[4.0 Regression] Two
   |generated   |consecutive movzbl are
   ||generated
   Target Milestone|--- |4.0.0


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

[Bug c/17934] gcc produces bad (misaligned?) sse2 code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:26 
---
No, the problem is that main is not aligned see that bug again.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main

[pinskia at gcc dot gnu dot org]

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

-- 


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

[Bug libstdc++/17937] Critical ~__pool troubles

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-11 17:26 ---
Created an attachment (id=7327)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7327&action=view)
Valgrind (2.2, --tool=memcheck) output


-- 


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

[Bug libstdc++/17937] Critical ~__pool troubles

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-11 17:38 ---
Forgot to add: to reproduce, remember to provide --enable-__cxa_atexit at build
time!

-- 


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:43 
---
This fixes the problem for me (basically what this patch does is gets rid of the check 
for CALL_EXPR 
because we do the fold later and it would not cause any other issue):
Diego, what do you think of this (with the additional updated comment)?
Index: tree-ssa.c
===

RCS file: /cvs/gcc/gcc/gcc/tree-ssa.c,v
retrieving revision 2.45
diff -u -p -r2.45 tree-ssa.c
--- tree-ssa.c  5 Oct 2004 13:57:06 -   2.45
+++ tree-ssa.c  11 Oct 2004 17:41:31 -
@@ -1048,7 +1048,7 @@ replace_immediate_uses (tree var, tree r
 Note that all this will become unnecessary soon.  This
 pass is being replaced with a proper copy propagation pass
 for 4.1 (dnovillo, 2004-09-17).  */
-  if (TREE_CODE (repl) != SSA_NAME)
+  if (TREE_CODE (repl) != SSA_NAME && TREE_CODE (stmt) != CALL_EXPR)
{
  tree tmp = stmt;
  fold_stmt (&tmp);


-- 


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

[Bug c++/17938] New: cannot assign result to const reference if copy ctor is not accessible

[bryner at brianryner dot com]

This code fails to compile on current mainline:

-
class A
{
  A(const A&);
};
 
const A GetA();
 
void caller()
{
  const A& a = GetA();
}
-

with this error:

access-const-ref.cpp: In function `void caller()':
access-const-ref.cpp:3: error: 'A::A(const A&)' is private
access-const-ref.cpp:10: error: within this context

It compiles fine on gcc 3.3.3.  compiler version:

$ gcc -v
Reading specs from /usr/gcc4/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/usr/gcc4 --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --disable-libgcj
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.0 20041011 (experimental)

-- 
   Summary: cannot assign result to const reference if copy ctor is
not accessible
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bryner at brianryner 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=17938

[Bug c++/17938] cannot assign result to const reference if copy ctor is not accessible

[bryner at brianryner dot com]

-- 
   What|Removed |Added

   Keywords||rejects-valid


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

[Bug rtl-optimization/17933] [4.0 Regression] ICE: in schedule_insns, at /sched-rgn.c:2555

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:53 
---
Here is a C example which is almost equivalent to the objective-C example:
struct d
{
  int a;
};
void abort(void);
typedef struct d (*f) (int i);
f ff(void);
void test1(void)
{
  if ((ff())(0).a != 0)
   abort();
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-11 17:53:41
   date||


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

[Bug c++/17938] cannot assign result to const reference if copy ctor is not accessible

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-11 17:57 
---
Please consult http://gcc.gnu.org/bugs.html#cxx_rvalbind.

There are other reports of the same bug.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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