[Bug c++/21274] SSA Crash, reproducable

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
07:14 ---
Hmm, "4.0.0 20050301", I am thinking you should try a 4.0.0 release compiler.

-- 


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

[Bug libfortran/20074] [4.0 only] reshape of pointer array segfaults at runtime

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-04-29 
07:29 ---
Fixed in 4.1, should be merged with 4.0

-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||4.1.0
Summary|reshape of pointer array|[4.0 only] reshape of
   |segfaults at runtime|pointer array segfaults at
   ||runtime
   Target Milestone|--- |4.0.1


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

[Bug ada/21276] New: Cross building gnats misses newlib headers

[corsepiu at gcc dot gnu dot org]

One-tree style bootstrapping a newlib-based cross GCC with ada enabled breaks
with this breakdown:

make[3]: Entering directory
`/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ada/rts'../../xgcc
-B../../ -c -DCROSS_COMPILE -DIN_GCC   `echo -g -O2  -fexceptions -DIN_RTS |sed
-e 's/-pedantic//g' -e 's/-Wtraditional//g'`  -I. -I.. -I../..
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../config
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../../include
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/..
-I./../.. adaint.c \
  -o adaint.o
In file included from adaint.c:59:
/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../tsystem.h:90:19:
error: stdio.h: No such file or directory
/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../tsystem.h:93:23:
error: sys/types.h: No such file or directory
/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../tsystem.h:96:19:
error: errno.h: No such file or directory

IMO, this indicates a bug inside of the GNAT configury, probably it is not aware
about newlib and therefore misses to acknowledge newlib's include directories
(Missing -I...)
 
Work around to this problem is to have a cross-gcc for the same target
previously installed, whose header sufficently match with the headers being used
by the build. In this case, bootstrapping seems to be using the already
installed headers instead of the headers of the GCC being build.

[I.e. 1. build and install gcc+newlib w/o gnat, then rebuild gcc w/ gnat].

-- 
   Summary: Cross building gnats misses newlib headers
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
com,laurent at guerby dot net,neroden at gcc dot gnu dot
org
  GCC host triplet: any
GCC target triplet: !=host


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

[Bug c++/21277] New: gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[info at yourkit dot com]

Summary: gcc 4.0 produces corrupted shared library if it is statically linked
with libstdc++ and etc. stuff


>g++ -v

Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: ../gcc-4.0.0/configure
--prefix=/home2/anton/opt/gcc-4.0.0-noshared --with-gnu-ld
--with-ld=/home2/anton/opt/bin/ld --with-gnu-as
--with-as=/home2/anton/opt/bin/as --disable-libgcj --enable-languages=c,c++
--disable-shared
Thread model: posix
gcc version 4.0.0

>uname -a

SunOS solaris 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-100

Source code of shared library:

=== q.cpp start ===

#include 

extern "C" {
  void foo() {
printf("sizeof(void*)=%d\n", sizeof(void*));
  }
}

=== q.cpp end ===

>g++ -m64 -fPIC q.cpp -shared -o libq.so
>file libq.so
libq.so:ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically
linked, not stripped
>ldd -Ur libq.so
libm.so.1 => /usr/lib/64/libm.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libdl.so.1 =>/usr/lib/64/libdl.so.1
/usr/platform/SUNW,Sun-Blade-100/lib/sparcv9/libc_psr.so.1

   unreferenced object=/usr/lib/64/libm.so.1; unused dependency of ./libq.so
   unused object=/usr/lib/64/libm.so.1; member of cyclic group [1]

Everything seems to be OK.

But when we load .so with the following simple program test.cpp, it prints error
message:

=== test.cpp start ===
#include   /* defines dlopen(), etc.   */
#include 
#include 

int main() {

  void* lib_handle = dlopen("/home2/anton/projects/frekenbok/libq.so", 
RTLD_LAZY);
  if (!lib_handle) {
  fprintf(stderr, "Error during dlopen(): %s\n", dlerror());
  exit(1);
  }

}
=== test.cpp end ===

>g++ -m64 test.cpp
>./a.out
Error during dlopen(): ld.so.1: a.out: fatal: relocation error: R_SPARC_WDISP30:
file /home2/anton/projects/frekenbok/libq.so: symbol strcpy: value 0x6053f9f7
does not fit


There is no problem if gcc is configured with shared enabled (i.e. without
"--disable-shared" flag), and .so is dynamically linked with libstdc++.so etc.
As well everything is fine in 32 bit mode (-m32), even statically linked.

So the problem appears _only_ in 64 bit mode and _only_ when resulting shared
library is statically linked.

-- 
   Summary: gcc 4.0 fails to statically link on Solaris SPARC 64 bit
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at yourkit dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/21276] Cross building gnats misses newlib headers

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-04-29 
07:33 ---
This is a duplicate of PR 6852

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug ada/6852] gnatlib fails to build with newlib because it doesn't set up the include path

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-04-29 
07:33 ---
*** Bug 21276 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||corsepiu at gcc dot gnu dot
   ||org


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

[Bug c++/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[info at yourkit dot com]

--- Additional Comments From info at yourkit dot com  2005-04-29 07:38 
---
Forgot to say: binutils 2.15

-- 


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

[Bug c++/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
07:39 ---
So you are not building with --with-pic?

-- 


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

[Bug libstdc++/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug libstdc++/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-29 07:54 
---
Also, please have a look to http://gcc.gnu.org/install/specific.html: it states
that stock binutils 2.15 is *broken* on this target and provides a pointer to
a patch (we received already lots of complaints from people using stock binutils
2.15, e.g., http://gcc.gnu.org/ml/libstdc++/2005-04/msg00237.html)

-- 


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

[Bug tree-optimization/21278] New: Move maximum out of a loop

[tkoenig at gcc dot gnu dot org]

This could help in reducing the amount of work for bounds
checking.

$ cat mymax.c
#include 
#include 

int main()
{
  char *p;
  int i,j,n;

  scanf("%d",&n);
  j = 0;
  for (i=0; i:;
  j = 0;
  i = 0;

:;
  j = MAX_EXPR ;
  i = i + 1;
  if (i != n.10) goto ; else goto ;

when the loop could be optimized to

if (n <= 0)
j = 0;
else
j = n-1;

-- 
   Summary: Move maximum out of a loop
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21279] New: static Derived-to-Base cast fails when ~Derived has run.

[murrayc at murrayc dot com]

In this test case, I cast a Derived* to a Base* after the destructor for the
Derived part has run. It's a strange thing to do, but I think the cast should
succeed, because it does not need instance information.

It only seems to happen when using virtual inheritance. We noticed this in
libsigc++.

-- 
   Summary: static Derived-to-Base cast fails when ~Derived has run.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: murrayc at murrayc dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21279] static Derived-to-Base cast fails when ~Derived has run.

[murrayc at murrayc dot com]

--- Additional Comments From murrayc at murrayc dot com  2005-04-29 08:20 
---
Created an attachment (id=8761)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8761&action=view)
test_castdeleted.cc

This fails (gives odd values) with g++ 3.3, 3.4 and 4.0.

-- 


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

[Bug c++/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[info at yourkit dot com]

--- Additional Comments From info at yourkit dot com  2005-04-29 08:27 
---
> So you are not building with --with-pic?

I'm sorry, where and when should I specify this option? gcc's configure --help
does not return this flag among possible options.

-- 
   What|Removed |Added

  Component|libstdc++   |c++


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

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

[jens dot maurer at gmx dot net]

This bug report may be related to bug 20584, but I've got standalone compilable
code that not only produces a warning, but also fails to link.

File t.h:

#pragma interface

template
struct C
{
  explicit C(const T& t) : a(t) { }
  virtual ~C() { }
  T a;
};


File f.cc:

#include "t.h"

struct A
{
  A() { }
  virtual ~A() { }
};

int main()
{
  A a;
  C c(a);
}


> g++ -g -Wall f.cc
t.h:7: warning: inline function 'A::A(const A&)' used but never defined
/tmp/ccM01LV4.o(.gnu.linkonce.t._ZN1CI1AEC1ERKS0_+0x21): In function `C::C(A
const&)':
/home/jmaurer/IS/isgbe/servers/kfi/f.cc:12: undefined reference to `A::A(A 
const&)'

It used to work with gcc 3.4.3.

At the very least, the warning message should have an instantiation backtrace so
that the user knows that the "used" comes from the instantiation of C.

-- 
   Summary: #pragma interface, templates, and "inline function used
but never defined"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jens dot maurer at gmx dot net
CC: Jens dot Maurer at is-teledata dot com,gcc-bugs at gcc
dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

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

[jens dot maurer at gmx dot net]

-- 
   What|Removed |Added

 CC||niemayer at isg dot de


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

[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-29 09:39 
---
Hum, maybe the fix is much simpler than I thought :)

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-29 09:39:07
   date||


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

[Bug rtl-optimization/21281] New: ICE with building newlib

[nathan at gcc dot gnu dot org]

The attached testcase, when compiled with ' -O2 -m68hc11' ICEs with an
unrecognizable insn

[EMAIL PROTECTED]:223>./cc1 -O2 -m68hc11 bug.i -quiet
bug.i: In function 'get_number':
bug.i:8: error: unrecognizable insn:
(insn 31 7 12 0 (set:HI (reg:HI 1 d [orig:56+2 ] [56])
(xor:HI (reg:HI 1 d [orig:56+2 ] [56])
(const_int -32768 [0x8000]))) -1 (nil)
(nil))
bug.i:8: internal compiler error: in extract_insn, at recog.c:2082
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: ICE with building newlib
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathan at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68hc11-elf


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

[Bug rtl-optimization/21281] ICE with building newlib

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2005-04-29 
09:46 ---
Created an attachment (id=8762)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8762&action=view)
testcase extracted from dprintf.c in newlib


-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-29 
09:51 ---
Tobi,

The reason that it works is that the value of *data that is passed to matmul 
points to the first element of the array or subarray.  matmul then calculates 
the number of elements from {stride, lbound, ubound} and C-indexing is used for 
athe aritmetic.  *base is therefore never needed.  This is illustrated by the 
following example:

Program pr18857a
  integer, parameter:: N = 5
  integer, parameter:: T = 4
  real(kind=T), dimension(:,:), allocatable, Target :: a, b, c
  real(kind=T), dimension(:,:), POINTER :: d, e
  real(kind=T), dimension(N,N)  :: x, y, z

  allocate (a(2*N, N), b(N, N), c(2*N, N))
  a = 1.0_T
  a(1:N,:) = 2.0_T
  b = 4.0_T
  x = 1.0_T
  y = 2.0_T

  z = 0.0_T
  z = matmul (x, y)
  if (sum (z) /= 250.0_T) call abort ()

  c = 0.0_T
  c = matmul (a(:,3:N), b(3:N,:))
  if (sum (c) /= 900.0_T) call abort ()

  deallocate (a, b, c)

end program pr18857a

I will not pollute Bugzilla with the entire tree dump but limit myself to 
reproducing the part just before and including the second call to matmul (lines 
384-386 of pr18857a.f90.t02.original)

parm.21.data = (real4[0:] *) (real4[0:] *) &(*b.data)[(3 - b.dim[0].lbound) 
* D.595 + (D.588 - b.dim[1].lbound) * D.596];
parm.21.offset = 0;
_gfortran_matmul_r4 (&c, &parm.20, &parm.21);

The (3 - b.dim[0].lbound) provides the offset to the data being multiplied. 
Earlier on in the tree dump, D.588 = b.dim[1].lbound;, so the second part of 
the offset is zero.  By some miracle, the front end does this correctly for 
every case that I can find. 
 

-- 


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

[Bug middle-end/21282] New: Converting floor into lfloor built-in function

[loki at gcc dot gnu dot org]

I have segfault for the following c code:

extern double floor (double);

long foo (float f)
{
  return (long) floor (f);
}

Command line:
arm-elf-gcc -c -O1 1.c

Output message:
1.c: In function 'foo':
1.c:5: internal compiler error: in expand_builtin_int_roundingfn, at 
builtins.c:2225
...

The environment was configured with:
binutils-2.14/configure --target=arm-elf
gcc/configure   --target=arm-elf --enable-language=c
newlib-1.12.0/configure --target/arm-elf

I have found the same problem for {i386, m68k, mips, ppc}-elf.

The bug appeared after the following patch:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00503.html

-- 
   Summary: Converting floor into lfloor built-in function
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loki at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,uros at gcc dot gnu dot
org
GCC target triplet: arm-elf i386-elf m68k-elf mips-elf ppc-elf


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

[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-29 10:24 
---
Indeed it is, sorry for the false alarm: our design is correct as-is, only the
typedef should be changed, I'm finishing testing the fix.

-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-04-29 10:28 
---
Thanks for investigating, I had an exchange with Paul Brook about this yesterday
on the mailing list, and I think I understand what's happening now.  Basically,
some of the information in the array descriptor is redundant.

An array element can be accessed in either of the following two ways:
   data[offset + index0*stride0 + index1*stride1 + index2*stride2]
and
   data[(index0-lbound0)*stride0 + (index1-lbound1)*stride1]

The library uses the latter way, so the offset is not needed there.

BTW this also answers the question of ssize_t vs size_t we were dicussing
before: correct overflow only plays a role when one uses the first way, and this
is only used in compiler-generated code.

The library only uses the latter kind of indexing and therefore using ssize_t
should work correctly under all circumstances. 

-- 


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

[Bug target/21153] gcc segfaults compiling qemu

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-04-29 10:50 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/16702] ICE (segfault) when compiling qemu with -O on x86_64 with gcc 3.4

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-04-29 10:50 ---
*** Bug 21153 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||developer at isl-gbr dot de


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

[Bug fortran/16861] segfault with doubly used module

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
10:56 ---
Subject: Bug 16861

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-29 10:56:18

Modified files:
gcc/fortran: ChangeLog resolve.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: pr16861.f90 

Log message:
PR fortran/16861
* resolve.c (resolve_variable): If e->symtree is not set, this
ought to be a FAILURE, and not a segfault.
* gfortran.dg/pr16861.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.42&r2=1.335.2.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.6&r2=1.34.2.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.148&r2=1.5084.2.149
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr16861.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.4.1



-- 


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

[Bug fortran/20807] compilation crashes when a module contains a procedure with the same name

[fxcoudert at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libfortran/21108] [4.0 only] reshape with order causes random results

[fxcoudert at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-29 11:02:27
   date||


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

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-04-29 12:04 ---
// Confirmed, reduced C testcase (compile with -O1 -funroll-loops):

void abort (void);

static int n;

static void __attribute__((noinline)) foo (void)
{
  n = 2;
}

static inline void bar (unsigned int k)
{
  if (k >= 256)
abort ();
}

int main (void)
{
  int i;

  foo ();
  for (i = 0; i < n; ++i)
bar ((unsigned char) i);
  return 0;
}


-- 
   What|Removed |Added

   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0 4.0.1 4.1.0
  Known to work||3.4.4
   Priority|P2  |P1
   Last reconfirmed|-00-00 00:00:00 |2005-04-29 12:04:03
   date||
Summary|Incorrect code with -   |[4.0/4.1 regression]
   |funroll-loops for multiple  |Incorrect code with -
   |targets with same code  |funroll-loops for multiple
   ||targets with same code
   Target Milestone|--- |4.0.1


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

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-29 12:17 
---
>From the *.t02.original dump, I'd say it is pretty much obvious what's wrong.
compute_inner_temp_size computes inner temporary size as:
D.905 = (int8) v[(int8) i.28 + -1].s;
but computes this before the 3 loops it then uses it in.
But that obviously depends on i.28 counter, which goes from 1 to 5 inclusive
in each of the loops.
But as D.905 assignment is evaluated before all of the 3 loops and not
inside of them as it IMHO should, it uses whatever value i.28 had before those
3 loops.  In the forall_3.f90 case there happens to be another loop before
that statement, so i.28 will be 6, so this will actually set
D.905 to (int8) v[(int8) 5].s, which is the first array element after the end
of the array.  It happens to be often 0 with -O2, which results in 0 bytes
being allocated for the temporary array, but it magically works with -O0,
because some fairly big number happens to be in that memory location.

i.28 = 1;
count.31 = 5;
while (1)
  {
if (count.31 <= 0) goto L.7; else (void) 0;
temp.29[mi.30] = v[(int8) i.28 + -1].valid;
mi.30 = mi.30 + 1;
i.28 = i.28 + 1;
count.31 = count.31 - 1;
  }
L.7:;
count1.32 = 0;
D.905 = (int8) v[(int8) i.28 + -1].s;
num.34 = 0;
i.28 = 1;
count.35 = 5;
while (1)
  {
if (count.35 <= 0) goto L.8; else (void) 0;
num.34 = num.34 + D.905;
i.28 = i.28 + 1;
count.35 = count.35 - 1;
  }
L.8:;
temp.36 = (int4[0:] *) _gfortran_internal_malloc64 (num.34 * 4);
mi.30 = 0;
i.28 = 1;
count.38 = 5;
while (1)
  {
if (count.38 <= 0) goto L.10; else (void) 0;
if (temp.29[mi.30])
  {
{
  int8 D.913;
  int4[0:] * D.912;
  int8 D.911;
  int4[0:] * D.910;

  count2.33 = 0;
  D.910 = v[(int8) (6 - i.28) + -1].p.data;
  D.911 = v[(int8) (6 - i.28) + -1].p.offset;
  D.912 = v[(int8) i.28 + -1].p.data;
  D.913 = v[(int8) i.28 + -1].p.offset;
  {
int8 D.915;
int8 S.37;

D.915 = v[(int8) (6 - i.28) + -1].p.dim[0].stride;
S.37 = 1;
while (1)
  {
if (S.37 > (int8) v[(int8) i.28 + -1].s) goto L.9; else
(void) 0;
(*temp.36)[count1.32 + count2.33] = (*D.910)[NON_LVALUE_EXPR
 * D.915 + D.911];
count2.33 = count2.33 + 1;
S.37 = S.37 + 1;
  }
L.9:;
  }
  count1.32 = count1.32 + D.905;
}
  }
else
  {
(void) 0;
  }
i.28 = i.28 + 1;
mi.30 = mi.30 + 1;
count.38 = count.38 - 1;
  }
L.10:;
count1.32 = 0;
mi.30 = 0;
i.28 = 1;
count.40 = 5;
while (1)
  {
if (count.40 <= 0) goto L.12; else (void) 0;
if (temp.29[mi.30])
  {
{
  int8 D.920;
  int4[0:] * D.919;

  count2.33 = 0;
  D.919 = v[(int8) i.28 + -1].p.data;
  D.920 = v[(int8) i.28 + -1].p.offset;
  {
int8 D.922;
int8 S.39;

D.922 = v[(int8) i.28 + -1].p.dim[0].stride;
S.39 = 1;
while (1)
  {
if (S.39 > (int8) v[(int8) i.28 + -1].s) goto L.11; else
(void) 0;
(*D.919)[NON_LVALUE_EXPR  * D.922 + D.920] =
(*temp.36)[count1.32 + count2.33];
count2.33 = count2.33 + 1;
S.39 = S.39 + 1;
  }
L.11:;
  }
  count1.32 = count1.32 + D.905;
}
  }
else
  {
(void) 0;
  }
i.28 = i.28 + 1;
mi.30 = mi.30 + 1;
count.40 = count.40 - 1;
  }
L.12:;
_gfortran_internal_free ((void *) temp.36);
  }

At least in this particular case, D.905 could be computed inside of the
first loop that uses it and not be computed in the subsequent loops at all
(simply use one counter that goes from 0 all the way up instead of using
two counters), but I'm not sure if that is possible for all FOREACH loops.

-- 


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

[Bug c++/20584] [4.0/4.1 Regression] inline function used but never defined

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
12:21 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||nerijus at users dot
   ||sourceforge dot net


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

[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[pinskia at gcc dot gnu dot org]

-- 
Bug 19159 depends on bug 20584, which changed state.

Bug 20584 Summary: [4.0/4.1 Regression] inline function used but never defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20584

   What|Old Value   |New Value

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
12:23 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-04-29 12:23:49
   date||
Summary|#pragma interface,  |[4.0/4.1 Regression] #pragma
   |templates, and "inline  |interface, templates, and
   |function used but never |"inline function used but
   |defined"|never defined"
   Target Milestone|--- |4.0.1


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

[Bug middle-end/21282] Converting floor into lfloor built-in function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
12:26 ---
Hmm:
  /* We shouldn't get here on targets without TARGET_C99_FUNCTIONS.
 ??? Perhaps convert (int)floorf(x) into (int)floor((double)x).  */



-- 


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

[Bug target/21283] New: ICE with doubles

[nathan at gcc dot gnu dot org]

the attached program, distilled from newlib's k_standard.c file, causes
an ICE at any optimization level.

[EMAIL PROTECTED]:270>./cc1 bug.i -quiet
bug.i: In function 'Foo':
bug.i:5: internal compiler error: in gen_lowpart_general, at rtlhooks.c:59
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: ICE with doubles
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathan at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: fr30-none-elf


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

[Bug target/21283] ICE with doubles

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2005-04-29 
12:32 ---
Created an attachment (id=8763)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8763&action=view)
testcase from newlib


-- 


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

[Bug middle-end/21107] [4.0/4.1 regression] internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-04-29 12:38 ---
Confirmed, note: the code is valid C.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
   Keywords|ice-on-invalid-code |ice-on-valid-code
  Known to fail||4.0.0 4.0.1 4.1.0
  Known to work||3.4.4 3.3.2
   Last reconfirmed|-00-00 00:00:00 |2005-04-29 12:38:31
   date||
Summary|internal compiler error: in |[4.0/4.1 regression]
   |expand_one_stack_var_at, at |internal compiler error: in
   |cfgexpand.c:476 |expand_one_stack_var_at, at
   ||cfgexpand.c:476


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

[Bug target/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |target


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

[Bug target/21281] ICE with building newlib

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug middle-end/21107] [4.0/4.1 regression] internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
12:58 ---
(In reply to comment #3)
> Confirmed, note: the code is valid C.

But we should be erroring out as the stack size is just too big for this target.

-- 


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

[Bug c++/21123] ICE in cp_expr_size, at cp/cp-objcp-common.c:101

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-04-29 13:12 ---
// Confirmed, smaller testcase:

struct U {
  U ();
  U (const U&);
};

struct T {
  U u;
};

struct V : T {
  int operator= (V &__x);
};

struct A {
  virtual V foo() const;
};

struct B : virtual public A {
  virtual V foo() const;
};

V B::foo() const
{
  V ret;
  return ret;
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|hppa-suse-linux-gnu |
   GCC host triplet|hppa-suse-linux-gnu |
   Last reconfirmed|-00-00 00:00:00 |2005-04-29 13:12:21
   date||


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

[Bug c/21284] New: AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

[bernard dot fouche at kuantic dot com]

The following example is a test case showing the problem.

The jump table is placed in .data on gcc-4.0.0 instead of flash memory.

Gcc-4.0.0 was configured that way:

./configure --prefix=/home/avrdev --target=avr --enable-languages=c,c++
--disable-nls

[EMAIL PROTECTED] stk500]$ cat testbug.c
unsigned long TestBug(int p)
{
  unsigned long  x=200;
  unsigned long  y=1;

  switch(p){
  case 0:
x=1;
y++;
break;
  case 1:
x=2;
y++;
break;
  case 2:
x=3;
y=2;
break;
  case 3:
x=4;
y=34;
break;
  case 4:
x=5;
y=38;
break;
  case 5:
x=6;
y=9;
break;
  case 6:
x=7;
y=71;
break;
  case 7:
x=8;
y=712;
break;
  case 8:
x=9;
y=-1;
break;
  case 9:
x=10;
y=10;
break;
  case 10:
x=11;
y=12;
break;
  case 11:
x=12;
y=123;
break;
  case 12:
x=13;
y=124;
break;
  case 13:
x=14;
y=122;
break;
  case 14:
x=15;
y=121;
break;
  case 15:
x=1;
y++;
break;
  case 16:
x=2;
y++;
break;
  case 17:
x=3;
y=2;
break;
  case 18:
x=4;
y=34;
break;
  case 19:
x=5;
y=38;
break;
  case 20:
x=6;
y=9;
break;
  case 21:
x=7;
y=71;
break;
  case 22:
x=8;
y=712;
break;
  case 23:
x=9;
y=-1;
break;
  case 24:
x=10;
y=10;
break;
  case 25:
x=11;
y=12;
break;
  case 26:
x=12;
y=123;
break;
  case 27:
x=13;
y=124;
break;
  case 28:
x=14;
y=122;
break;
  case 29:
x=15;
y=121;
break;
  }

  return x*y;
}
[EMAIL PROTECTED] stk500]$ avr-gcc --version
avr-gcc (GCC) 3.4.3
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.

[EMAIL PROTECTED] stk500]$ avr-gcc -Os -Wall -c testbug.c
[EMAIL PROTECTED] stk500]$ avr-objdump -s testbug.o

testbug.o: file format elf32-avr

Contents of section .text:
  cf93df93 c8ecd0e0 e0e0f0e0 21e030e0  !.0.
 0010 40e050e0 aa2797fd a095ba2f 8e319105  @.P..'./.1..
 0020 08f083c0 80509040 8f939f93 0895c1e0  [EMAIL PROTECTED]
 0030 d0e0e0e0 f0e009c0 c2e0d0e0 e0e0f0e0  
 0040 43c0c3e0 d0e0e0e0 f0e022e0 30e040e0  C."[EMAIL PROTECTED]
 0050 50e06bc0 c4e0d0e0 e0e0f0e0 22e230e0  P.k.".0.
 0060 40e050e0 62c0c5e0 d0e0e0e0 f0e026e2  @.P.b.&.
 0070 30e040e0 50e059c0 c6e0d0e0 e0e0f0e0  [EMAIL PROTECTED]
 0080 29e030e0 40e050e0 50c0c7e0 d0e0e0e0  )[EMAIL PROTECTED]
 0090 f0e027e4 30e040e0 50e047c0 c8e0d0e0  ..'[EMAIL PROTECTED]
 00a0 e0e0f0e0 28ec32e0 40e050e0 3ec0c9e0  ([EMAIL PROTECTED]>...
 00b0 d0e0e0e0 f0e02fef 3fef4fef 5fef35c0  ../.?.O._.5.
 00c0 cae0d0e0 e0e0f0e0 2c2f3d2f 4e2f5f2f  ,/=/N/_/
 00d0 2cc0cbe0 d0e0e0e0 f0e02ce0 30e040e0  ,.,[EMAIL PROTECTED]
 00e0 50e023c0 cce0d0e0 e0e0f0e0 2be730e0  P.#.+.0.
 00f0 40e050e0 1ac0cde0 d0e0e0e0 f0e02ce7  @.P...,.
 0100 30e040e0 50e011c0 cee0d0e0 e0e0f0e0  [EMAIL PROTECTED]
 0110 2ae730e0 40e050e0 08c0cfe0 d0e0e0e0  [EMAIL PROTECTED]
 0120 f0e029e7 30e040e0 50e06c2f 7d2f8e2f  ..)[EMAIL PROTECTED]/}/./
 0130 9f2f00d0 b92fa82f 972f862f 682f792f  ./..././././h/y/
 0140 8a2f9b2f df91cf91 0895   ././..  
Contents of section .progmem.gcc_sw_table:
  00c000c0 00c000c0 00c000c0 00c000c0  
 0010 00c000c0 00c000c0 00c000c0 00c000c0  
 0020 00c000c0 00c000c0 00c000c0 00c000c0  
 0030 00c000c0 00c000c0 00c000c0   
[EMAIL PROTECTED] stk500]$ avr-gcc --version
avr-gcc (GCC) 4.0.0
Copyright (C) 2005 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.

[EMAIL PROTECTED] stk500]$ avr-gcc -Os -Wall -c testbug.c
[EMAIL PROTECTED] stk500]$ avr-objdump -s testbug.o

testbug.o: file format elf32-avr

Contents of section .text:
  f92fe82f 4e9760f4 e050f040 09946fe0  ././[EMAIL PROTECTED]
 0010 70e080e0 90e029e7 30e040e0 50e07ec0  p.)[EMAIL PROTECTED]
 0020 68ec70e0 80e090e0 21e030e0 40e050e0  [EMAIL PROTECTED]
 0030 75c061e0 70e080e0 90e004c0 62e070e0  u.a.p...b.p.
 0040 80e090e0 22e030e0 40e050e0 67c063e0  "[EMAIL PROTECTED]
 0050 70e080e0 90e0f6cf 64e070e0 80e090e0  p...d.p.
 0060 22e230e0 40e050e0 59c065e0 70e080e0  "[EMAIL PROTECTED]
 0070 90e026e2 30e040e0 50e050c0 66e070e0  ..&[EMAIL PROTECTED]
 0080 80e090e0 29e030e0 40e050e0 47c067e0  )[EMAIL PROTECTED]
 0090 70e080e0 90e027e4 30e040e0 50e03ec0  p.'[EMAIL PROTECTED]>.
 00a0 68e070e0 80e090e0 28ec32e0 40e050e0  h.p.([EMAIL PROTECTED]
 00b0 35c069e0 70e080e0 90e02fef 3fef4fef  5.i.p./.?.O.
 00c0 5fef2cc0 6ae070e0 80e090e0 2ae030e0  _.,.j.p.*.0.
 00d0 40e050e0 23c06be0 70e080e0 90e02ce0  

[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|c   |target


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

[Bug c++/21274] SSA Crash, reproducable

[callahan at sci dot utah dot edu]

--- Additional Comments From callahan at sci dot utah dot edu  2005-04-29 
13:57 ---
Not me.  I have lots to do and this is relatively unimportant.  I just thought
someone there might like the short test case.


-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-29 
14:03 ---
On i386-linux, I get:

Running LAPACK tests on gfortran version 4.1.0 20050429 (experimental)
Using optimisation flags: -O0
 CST drivers:  1 out of  11664 tests failed to pass the threshold
 CST:2 out of  4662 tests failed to pass the threshold
 CST:2 out of  4662 tests failed to pass the threshold
 CST drivers:  1 out of  11664 tests failed to pass the threshold
 DES:1 out of  3270 tests failed to pass the threshold
 DSX:1 out of  3500 tests failed to pass the threshold
 DXV drivers:200 out of   5000 tests failed to pass the threshold
 SXV drivers: 37 out of   5000 tests failed to pass the threshold
 SST:2 out of  4662 tests failed to pass the threshold
 SST drivers:  1 out of  14256 tests failed to pass the threshold
 ZXV drivers: 24 out of   5000 tests failed to pass the threshold
 ZGG drivers:  1 out of   1268 tests failed to pass the threshold

Running LAPACK tests on gfortran version 4.1.0 20050429 (experimental)
Using optimisation flags: -O1
 CST:2 out of  4662 tests failed to pass the threshold
 DXV drivers:200 out of   5000 tests failed to pass the threshold
 SXV drivers: 37 out of   5000 tests failed to pass the threshold
 SST:1 out of  4662 tests failed to pass the threshold
 SST drivers:  1 out of  14256 tests failed to pass the threshold
 ZXV drivers: 24 out of   5000 tests failed to pass the threshold

-O2 segfaults, I'm looking into it.

-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-29 
14:11 ---
This breaks BLAS (optimzation >= -O2), the major Fortran library. The whole
fortran front-end is useless in this state.

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Last reconfirmed|2005-04-14 20:44:19 |2005-04-29 14:11:54
   date||


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-04-29 
14:16 ---

Working on it today.  Kazu, I hope you don't mind if I take it?

-- 
   What|Removed |Added

 AssignedTo|kazu at cs dot umass dot edu|dnovillo at gcc dot gnu dot
   ||org


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

[Bug libgcj/21285] New: gij fails to handle NullPointerException exception

[tsv at solvo dot ru]

The following simple program prints "Aborted" on linux alpha if it is compiled
to byte code and later executed by "gij". The same program works correctly if
compiled to executable. (ant crashes with segmentation fault, but I could not
provide simple testcase :( ).

gij (GNU libgcj) version 4.0.0 20050423 (Red Hat 4.0.0-1)
glibc 2.3.4


import java.util.*;

public class Test
{
   public static void main(String argv[])
 {
Vector a = new Vector();
Vector b = null;

a.add("haha");
b.add("haha");

System.out.println("Test");
 }
}

Thank you.

-- 
   Summary: gij fails to handle NullPointerException exception
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: alpha-redhat-linux
  GCC host triplet: alpha-redhat-linux
GCC target triplet: alpha-redhat-linux


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-29 14:35 
---
Diego, no, I don't mind.

But I have a patch whose bootstrap is almost over and
regression testing is about to start.

This patch does not break g++dg/tree-ssa/pr18178.C unlike my previous patch.

Let me attach my patch (and some analysis) just FWIW.



-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-29 14:55 
---
Subject: Re:  [4.1 Regression] ICE in
 set_value_range building 176.gcc with -O2

Hi Diego,

> Kazu, did you mail your patch before attaching it to bugzilla?  I
> haven't received it.  The same thing happened to your previous
> patch for this PR and I missed it the first time.

No, I did not send my previous to gcc-patches@ because I was not fully
satified with it.  Although I tested the patch, it broke pr18178.C,
and I did not analyze the failure at that time.

I have not sent my current patch to gcc-patches@ yet because I have
not finished testing it.  This time I will unless you beat me to it.

Kazu Hirata


-- 


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-29 
14:59 ---
Subject: Re:  MATMUL failing with ALLOCATED matrices, unless base indices given

Tobi,

> The library uses the latter way, so the offset is not needed there.
>
Exactly - I was aware of this because the namelist functions do not use 
base/offset at all.

> BTW this also answers the question of ssize_t vs size_t we were dicussing
> before: correct overflow only plays a role when one uses the first way, 
> and this
> is only used in compiler-generated code.

Yes, that is the point that Thomas was making, when he raised it in the 
first place.

>
> The library only uses the latter kind of indexing and therefore using 
> ssize_t
> should work correctly under all circumstances.

Again, exactly.

As for the care that I am taking - after the business with namelist, I feel 
like the monkey and the billiard ball- I'll see if I can find it on the web. 
You will see why it is appropriate.

Paul




-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[dnovillo at redhat dot com]

--- Additional Comments From dnovillo at redhat dot com  2005-04-29 14:59 
---
Subject: Re:  [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

On Fri, Apr 29, 2005 at 02:55:58PM -, kazu at cs dot umass dot edu wrote:

> I have not sent my current patch to gcc-patches@ yet because I have
> not finished testing it.  This time I will unless you beat me to it.
> 
Oh, OK.  No, that's fine.  I'm now analyzing the test case.  I'll
check out your patch in a little while, if it matches what I
found, then it's OK to go in.


Diego.


-- 


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

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-29 15:20 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/21277] gcc 4.0 fails to statically link on Solaris SPARC 64 bit

[info at yourkit dot com]

--- Additional Comments From info at yourkit dot com  2005-04-29 15:25 
---
I have re-installed the recommended at http://gcc.gnu.org/install/specific.html
binutils (branch binutils-2_15-branch from CVS) AND even re-compiled gcc after 
that.

It doesn't help - the problem remains.


-- 
   What|Removed |Added

  Component|target  |c++


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

[Bug fortran/18824] [g77 regression] ENTRY with alternate return causes compiler segfault

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
15:32 ---
Subject: Bug 18824

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 15:31:39

Modified files:
gcc/fortran: ChangeLog 
gcc/testsuite  : ChangeLog 
gcc/fortran: trans-expr.c resolve.c trans-types.c gfortran.h 
 decl.c trans-decl.c trans-array.c 
Added files:
gcc/testsuite/gfortran.dg: entry_4.f90 
gcc/testsuite/gfortran.fortran-torture/execute: entry_5.f90 
entry_2.f90 
entry_3.f90 
entry_7.f90 
entry_6.f90 
entry_4.f90 
entry_1.f90 
entry_8.f90 

Log message:
2005-04-29  Jakub Jelinek  <[EMAIL PROTECTED]>

PR fortran/13082
PR fortran/18824
* trans-expr.c (gfc_conv_variable): Handle return values in functions
with alternate entry points.
* resolve.c (resolve_entries): Remove unnecessary string termination
after snprintf.  Set result of entry master.
If all entries have the same type, set entry master's type
to that common type, otherwise set mixed_entry_master attribute.
* trans-types.c (gfc_get_mixed_entry_union): New function.
(gfc_get_function_type): Use it for mixed_entry_master functions.
* gfortran.h (symbol_attribute): Add mixed_entry_master bit.
* decl.c (gfc_match_entry): Set entry->result properly for
function ENTRY.
* trans-decl.c (gfc_get_symbol_decl): For entry_master, skip over
__entry argument.
(build_entry_thunks): Handle return values in entry thunks.
Clear BT_CHARACTER's ts.cl->backend_decl, so that it is not
shared between multiple contexts.
(gfc_get_fake_result_decl): Use DECL_ARGUMENTS from
current_function_decl instead of sym->backend_decl.  Skip over
entry master's entry id argument.  For mixed_entry_master entries or
their results, return a COMPONENT_REF of the fake result.
(gfc_trans_deferred_vars): Don't warn about missing return value if
at least one entry point uses RESULT.
(gfc_generate_function_code): For entry master returning
CHARACTER, copy ts.cl->backend_decl to all entry result syms.
* trans-array.c (gfc_trans_dummy_array_bias): Don't consider return
values optional just because they are in entry master.

* gfortran.dg/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_1.f90: New test.
* gfortran.fortran-torture/execute/entry_2.f90: New test.
* gfortran.fortran-torture/execute/entry_3.f90: New test.
* gfortran.fortran-torture/execute/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_5.f90: New test.
* gfortran.fortran-torture/execute/entry_6.f90: New test.
* gfortran.fortran-torture/execute/entry_7.f90: New test.

2005-04-29  Tobias Schl"uter  <[EMAIL PROTECTED]>

* gfortran.fortran-torture/execute/entry_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.412&r2=1.413
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5415&r2=1.5416
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&r1=1.40&r2=1.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.67&r2=1.68
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&r1=1.34&r2=1.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.42&r2=1.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_7.f90.diff?cvs

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
15:32 ---
Subject: Bug 13082

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 15:31:39

Modified files:
gcc/fortran: ChangeLog 
gcc/testsuite  : ChangeLog 
gcc/fortran: trans-expr.c resolve.c trans-types.c gfortran.h 
 decl.c trans-decl.c trans-array.c 
Added files:
gcc/testsuite/gfortran.dg: entry_4.f90 
gcc/testsuite/gfortran.fortran-torture/execute: entry_5.f90 
entry_2.f90 
entry_3.f90 
entry_7.f90 
entry_6.f90 
entry_4.f90 
entry_1.f90 
entry_8.f90 

Log message:
2005-04-29  Jakub Jelinek  <[EMAIL PROTECTED]>

PR fortran/13082
PR fortran/18824
* trans-expr.c (gfc_conv_variable): Handle return values in functions
with alternate entry points.
* resolve.c (resolve_entries): Remove unnecessary string termination
after snprintf.  Set result of entry master.
If all entries have the same type, set entry master's type
to that common type, otherwise set mixed_entry_master attribute.
* trans-types.c (gfc_get_mixed_entry_union): New function.
(gfc_get_function_type): Use it for mixed_entry_master functions.
* gfortran.h (symbol_attribute): Add mixed_entry_master bit.
* decl.c (gfc_match_entry): Set entry->result properly for
function ENTRY.
* trans-decl.c (gfc_get_symbol_decl): For entry_master, skip over
__entry argument.
(build_entry_thunks): Handle return values in entry thunks.
Clear BT_CHARACTER's ts.cl->backend_decl, so that it is not
shared between multiple contexts.
(gfc_get_fake_result_decl): Use DECL_ARGUMENTS from
current_function_decl instead of sym->backend_decl.  Skip over
entry master's entry id argument.  For mixed_entry_master entries or
their results, return a COMPONENT_REF of the fake result.
(gfc_trans_deferred_vars): Don't warn about missing return value if
at least one entry point uses RESULT.
(gfc_generate_function_code): For entry master returning
CHARACTER, copy ts.cl->backend_decl to all entry result syms.
* trans-array.c (gfc_trans_dummy_array_bias): Don't consider return
values optional just because they are in entry master.

* gfortran.dg/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_1.f90: New test.
* gfortran.fortran-torture/execute/entry_2.f90: New test.
* gfortran.fortran-torture/execute/entry_3.f90: New test.
* gfortran.fortran-torture/execute/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_5.f90: New test.
* gfortran.fortran-torture/execute/entry_6.f90: New test.
* gfortran.fortran-torture/execute/entry_7.f90: New test.

2005-04-29  Tobias Schl"uter  <[EMAIL PROTECTED]>

* gfortran.fortran-torture/execute/entry_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.412&r2=1.413
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5415&r2=1.5416
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&r1=1.40&r2=1.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.67&r2=1.68
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&r1=1.34&r2=1.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.42&r2=1.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_7.f90.diff?cvs

[Bug c++/21286] New: GNU extension stdio_filebuf problems when reading from pipe

[ralfixx at gmx dot de]

Attach stdin (or any other FILE*) to an iostream via the rdbuf() created from a
FILE* by using the GNU extension stdio_filebuf() (see attached C++-File).

Input is just some big file with +11MB:

% wc -c big_file
11601584 big_file

This reads incorrect number of bytes when stdin is a pipe and using an block
size which is not some power of 2. The number of bytes read differs from run to 
run.
% cat big_file | ./t400 8687
total bytes read 9347072, blocks 1076
% cat big_file | ./t400 8687
total bytes read 978944, blocks 113
% cat big_file | ./t400 8687
total bytes read 8679424, blocks 1000
% cat big_file | ./t400 8687
total bytes read 3424256, blocks 395
% cat big_file | ./t400 8687
total bytes read 11601584, blocks 1336
% cat big_file | ./t400 2048
total bytes read 11601584, blocks 5665
% cat big_file | ./t400 2048
total bytes read 11601584, blocks 5665

No errors when stdin is redirected directly to the file.  

% ./t400 8676 < big_file
total bytes read 11601584, blocks 1338
% ./t400 8676 < big_file
total bytes read 11601584, blocks 1338
% ./t400 8676 < big_file
total bytes read 11601584, blocks 1338
% ./t400 8676 < big_file
total bytes read 11601584, blocks 1338

Also no problems when reading in 2048 or 4096 blocks:

% cat big_file | ./t400 2048
total bytes read 11601584, blocks 5665
% cat big_file | ./t400 2048
total bytes read 11601584, blocks 5665
% cat big_file | ./t400 2048
total bytes read 11601584, blocks 5665

% cat big_file | ./t400 4096
total bytes read 11601584, blocks 2833
% cat big_file | ./t400 4096
total bytes read 11601584, blocks 2833
% cat big_file | ./t400 4096
total bytes read 11601584, blocks 2833

Same problem on HP-UX 10.20 with gcc-4.0.0 (and 3.4.3 if it matters).

The same program runs w/o problems in gcc-3.4.1 and gcc-3.3.3 on the same 
platforms.

I actually had a shell loop trying block sizes from 1 to 1 to find the
problematic ones, so if 8687 does not reproduce the bug, try the follwoing shell
loop:

i=8000
while test $i -lt 9000 ; do
  echo -e "$i: \\c"
  cat big_file | ./t400 $i
  i=`echo $i+1 | bc`
done


R'

-- 
   Summary: GNU extension stdio_filebuf problems when reading from
pipe
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralfixx at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/21286] GNU extension stdio_filebuf problems when reading from pipe

[ralfixx at gmx dot de]

--- Additional Comments From ralfixx at gmx dot de  2005-04-29 15:56 ---
Created an attachment (id=8765)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8765&action=view)
C++ source file to show the problem

g++ -o t400 t.cxx
usage: t400 [blocksize]

t400 reads all input and counts the bytes.  At EOF, a summary is printed.  The
total bytes read should match the input file size.

-- 


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

[Bug c++/21286] GNU extension stdio_filebuf problems when reading from pipe

[ralfixx at gmx dot de]

--- Additional Comments From ralfixx at gmx dot de  2005-04-29 15:58 ---
(From update of attachment 8765)
The last paragraph in the attachted file is wrong, the bug is reproducable on
linux now.


-- 


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

[Bug rtl-optimization/16702] ICE (segfault) when compiling qemu with -O on x86_64 with gcc 3.4

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-04-29 
16:01 ---
Is this a regression?

-- 


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

[Bug fortran/18824] [g77 regression] ENTRY with alternate return causes compiler segfault

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
16:04 ---
Subject: Bug 18824

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-29 16:01:17

Modified files:
gcc/fortran: ChangeLog 
gcc/testsuite  : ChangeLog 
gcc/fortran: trans-expr.c resolve.c trans-types.c gfortran.h 
 decl.c trans-decl.c trans-array.c 
Added files:
gcc/testsuite/gfortran.dg: entry_4.f90 
gcc/testsuite/gfortran.fortran-torture/execute: entry_5.f90 
entry_2.f90 
entry_3.f90 
entry_7.f90 
entry_6.f90 
entry_4.f90 
entry_1.f90 
entry_8.f90 

Log message:
2005-04-29  Jakub Jelinek  <[EMAIL PROTECTED]>

PR fortran/13082
PR fortran/18824
* trans-expr.c (gfc_conv_variable): Handle return values in functions
with alternate entry points.
* resolve.c (resolve_entries): Remove unnecessary string termination
after snprintf.  Set result of entry master.
If all entries have the same type, set entry master's type
to that common type, otherwise set mixed_entry_master attribute.
* trans-types.c (gfc_get_mixed_entry_union): New function.
(gfc_get_function_type): Use it for mixed_entry_master functions.
* gfortran.h (symbol_attribute): Add mixed_entry_master bit.
* decl.c (gfc_match_entry): Set entry->result properly for
function ENTRY.
* trans-decl.c (gfc_get_symbol_decl): For entry_master, skip over
__entry argument.
(build_entry_thunks): Handle return values in entry thunks.
Clear BT_CHARACTER's ts.cl->backend_decl, so that it is not
shared between multiple contexts.
(gfc_get_fake_result_decl): Use DECL_ARGUMENTS from
current_function_decl instead of sym->backend_decl.  Skip over
entry master's entry id argument.  For mixed_entry_master entries or
their results, return a COMPONENT_REF of the fake result.
(gfc_trans_deferred_vars): Don't warn about missing return value if
at least one entry point uses RESULT.
(gfc_generate_function_code): For entry master returning
CHARACTER, copy ts.cl->backend_decl to all entry result syms.
* trans-array.c (gfc_trans_dummy_array_bias): Don't consider return
values optional just because they are in entry master.

* gfortran.dg/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_1.f90: New test.
* gfortran.fortran-torture/execute/entry_2.f90: New test.
* gfortran.fortran-torture/execute/entry_3.f90: New test.
* gfortran.fortran-torture/execute/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_5.f90: New test.
* gfortran.fortran-torture/execute/entry_6.f90: New test.
* gfortran.fortran-torture/execute/entry_7.f90: New test.

2005-04-29  Tobias Schl"uter  <[EMAIL PROTECTED]>

* gfortran.fortran-torture/execute/entry_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.43&r2=1.335.2.44
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.149&r2=1.5084.2.150
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.38.2.2&r2=1.38.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.7&r2=1.34.2.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.37.10.2&r2=1.37.10.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.5&r2=1.58.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.2.1&r2=1.31.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.2.1&r2=1.54.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.2.1&r2=1.39.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.di

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
16:04 ---
Subject: Bug 13082

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-29 16:01:17

Modified files:
gcc/fortran: ChangeLog 
gcc/testsuite  : ChangeLog 
gcc/fortran: trans-expr.c resolve.c trans-types.c gfortran.h 
 decl.c trans-decl.c trans-array.c 
Added files:
gcc/testsuite/gfortran.dg: entry_4.f90 
gcc/testsuite/gfortran.fortran-torture/execute: entry_5.f90 
entry_2.f90 
entry_3.f90 
entry_7.f90 
entry_6.f90 
entry_4.f90 
entry_1.f90 
entry_8.f90 

Log message:
2005-04-29  Jakub Jelinek  <[EMAIL PROTECTED]>

PR fortran/13082
PR fortran/18824
* trans-expr.c (gfc_conv_variable): Handle return values in functions
with alternate entry points.
* resolve.c (resolve_entries): Remove unnecessary string termination
after snprintf.  Set result of entry master.
If all entries have the same type, set entry master's type
to that common type, otherwise set mixed_entry_master attribute.
* trans-types.c (gfc_get_mixed_entry_union): New function.
(gfc_get_function_type): Use it for mixed_entry_master functions.
* gfortran.h (symbol_attribute): Add mixed_entry_master bit.
* decl.c (gfc_match_entry): Set entry->result properly for
function ENTRY.
* trans-decl.c (gfc_get_symbol_decl): For entry_master, skip over
__entry argument.
(build_entry_thunks): Handle return values in entry thunks.
Clear BT_CHARACTER's ts.cl->backend_decl, so that it is not
shared between multiple contexts.
(gfc_get_fake_result_decl): Use DECL_ARGUMENTS from
current_function_decl instead of sym->backend_decl.  Skip over
entry master's entry id argument.  For mixed_entry_master entries or
their results, return a COMPONENT_REF of the fake result.
(gfc_trans_deferred_vars): Don't warn about missing return value if
at least one entry point uses RESULT.
(gfc_generate_function_code): For entry master returning
CHARACTER, copy ts.cl->backend_decl to all entry result syms.
* trans-array.c (gfc_trans_dummy_array_bias): Don't consider return
values optional just because they are in entry master.

* gfortran.dg/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_1.f90: New test.
* gfortran.fortran-torture/execute/entry_2.f90: New test.
* gfortran.fortran-torture/execute/entry_3.f90: New test.
* gfortran.fortran-torture/execute/entry_4.f90: New test.
* gfortran.fortran-torture/execute/entry_5.f90: New test.
* gfortran.fortran-torture/execute/entry_6.f90: New test.
* gfortran.fortran-torture/execute/entry_7.f90: New test.

2005-04-29  Tobias Schl"uter  <[EMAIL PROTECTED]>

* gfortran.fortran-torture/execute/entry_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.43&r2=1.335.2.44
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.149&r2=1.5084.2.150
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.38.2.2&r2=1.38.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.7&r2=1.34.2.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.37.10.2&r2=1.37.10.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.5&r2=1.58.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.2.1&r2=1.31.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.2.1&r2=1.54.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.2.1&r2=1.39.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/entry_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/entry_5.f90.di

[Bug tree-optimization/21272] SSA_NAME def follows use with -ftree-vectorize

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
16:14 ---
Subject: Bug 21272

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 16:10:13

Modified files:
gcc: ChangeLog tree-if-conv.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/vect: vect-ifcvt-10.c 

Log message:
PR tree-optimization/21272
* tree-if-conv.c (find_phi_replacement_condition): Fix think-o.

* gcc.dg/vect/vect-ifcvt-10.c: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8529&r2=2.8530
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-if-conv.c.diff?cvsroot=gcc&r1=2.38&r2=2.39
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5416&r2=1.5417
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-ifcvt-10.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-29 16:25 
---
Just checked in a patch.


-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-29 16:27 
---
Just checked in a patch.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

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

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2005-04-29 16:29 ---
Subject: Re:  MATMUL failing with ALLOCATED matrices,
 unless base indices given

paulthomas2 at wanadoo dot fr wrote:
> --- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-29 
> 14:59 ---
> Exactly - I was aware of this because the namelist functions do not use 
> base/offset at all.
> Yes, that is the point that Thomas was making, when he raised it in the 
> first place.
> Again, exactly.

Looks like I'm really slow :-) I'm all in favor of Thomas ssize_t patch now.

> As for the care that I am taking - after the business with namelist, I feel 
> like the monkey and the billiard ball- I'll see if I can find it on the web. 
> You will see why it is appropriate.

I broke the bootstrap yesterday, I guess I'm in no position to judge how
careful other people are :-)

- Tobi


-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
16:29 ---
Subject: Bug 21030

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 16:23:20

Modified files:
gcc: ChangeLog tree-vrp.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: pr21030.c 

Log message:
gcc/
PR tree-optimization/21030
* tree-vrp.c (adjust_range_with_scev): Do not create invalid
ranges where VR->MAX is smaller than VR->MIN.

testsuite/
PR tree-optimization/21030
* gcc.dg/tree-ssa/pr21030.c: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8530&r2=2.8531
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.13&r2=2.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5417&r2=1.5418
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21030.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug c++/21287] New: Problems while compiling with some math functions.

[sreevatsan at gmail dot com]

I am trying to complie a simple program with math functions sqrt() and fabs
using gcc 3.4.3  (Red Hat 3.4.3-9.EL4). I am not able to compile without
including #include  but same code works with earlier versions of gcc
3.3.3 (Suse ) and gcc 3.3.3 (Red Hat 3.2.3-42).

Code:
#include
int main()
{
double k =1.4;
cout< and would like to migrate to gcc 
3.4.3.

Please do advice.

Thanks,

-- 
   Summary: Problems while compiling with some math functions.
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sreevatsan at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21286] GNU extension stdio_filebuf problems when reading from pipe

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-29 17:28 
---
Indeed, this is easily explained considering that we have a new optimization
that issues larger underlying read sys-calls (have a look to xsgetn in 
fstream.tcc
to see what I mean): when everything goes well ;) are you noticing measurable
performance improvements? When pipes are involved, I'm not sure we can call this
a bug, because, when 27.6.1.3/28 talks about "end-of-file occurs on the input
sequence" it refers, in this case, not to the underlying file that you are 
piping
but to the pipe itself and, at that moment, indeed the pipe cannot make 
available
all the characters requested. I'd like to know your opinion, as a user: are you
noticing worthwhile performance improvements? Would you consider very annoying
trying to read again (calling clear()), when pipes are used? In case, disabling
the optimization to be safe would be very easy.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/21288] New: fortran bootstrap issues

[bh at techhouse dot brown dot edu]

(1) if you download core, g++, and fortran, only c and c++ are built; fortran is
not, unlike in prior releases.

(2) configuring with --enable-languages=c,c++,f95 and no other options; then
using make profiledbootstrap, I get an ICE:

/bin/sh ./libtool --mode=compile /var/tmp/bhudson-gcc/4.0.0/gcc/gfortran -B/var/
tmp/bhudson-gcc/4.0.0/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686
-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/l
ocal/i686-pc-linux-gnu/sys-include  -Wall -fno-repack-arrays -fno-underscoring -
c -o selected_int_kind.lo `test -f 'intrinsics/selected_int_kind.f90' || echo '/
afs/cs/usr/bhudson/gcc/gcc-4.0.0/libgfortran/'`intrinsics/selected_int_kind.f90
/var/tmp/bhudson-gcc/4.0.0/gcc/gfortran -B/var/tmp/bhudson-gcc/4.0.0/gcc/ -B/usr
/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/
local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-includ
e -Wall -fno-repack-arrays -fno-underscoring -c /afs/cs/usr/bhudson/gcc/gcc-4.0.
0/libgfortran/intrinsics/selected_int_kind.f90  -fPIC -DPIC -o .libs/selected_in
t_kind.o
:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake[3]: *** [selected_int_kind.lo] Error 1
gmake[3]: Leaving directory `/usr/tmp/bhudson-gcc/4.0.0/i686-pc-linux-gnu/libgfo
rtran'

Manually running that compile with -save-temps doesn't appear to create any 
files.

-- 
   Summary: fortran bootstrap issues
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bh at techhouse dot brown dot edu
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=21288

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

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-04-29 17:50 
---
dpatel checked in a fix referencing PR 21272.  That patch fixes the problems
I reported in 21272.

-- 


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

[Bug c++/21287] Problems while compiling with some math functions.

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-29 17:52 
---
Really, you have to include math.h: the ISO Standard that we are implementing
is *very* clear about that, sorry. Much better, please move to  and
 in namespace std:: take seriously the warning! Thanks.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:28 ---
As per comment #37, closing as WONTFIX.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords|wrong-code  |
 Resolution||WONTFIX


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

[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368

[mmitchel at gcc dot gnu dot org]

-- 
Bug 20280 depends on bug 19199, which changed state.

Bug 19199 Summary: [3.3/3.4 Regression] Wrong warning about returning a 
reference to a temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX

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

[Bug middle-end/18071] [3.4/4.0/4.1 Regression] -Winline does not respect -fno-default-inline

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:30 ---
Removing rejects-valid marker; spurious warnings do not count as rejects-valid.

-- 
   What|Removed |Added

   Keywords|rejects-valid   |


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

[Bug target/15155] [3.4 regression][sh-linux] displacement overflows 12-bit field

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:35 ---
Removed target milestone; SH is not a primary or secondary target.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug java/19285] Interfaces not initialized by static field access

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:35 ---
Subject: Bug 19285

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:35:37

Modified files:
libjava: prims.cc link.cc ChangeLog 
libjava/include: jvm.h 

Log message:
2005-04-27  Andrew Haley  <[EMAIL PROTECTED]>

PR java/19285
* prims.cc (_Jv_ResolvePoolEntry): New function.
* include/jvm.h (_Jv_Linker::find_field): New arg: found_class.
* link.cc (_Jv_Linker::find_field): New arg: found_class.
(resolve_pool_entry): Initialize the class in which a field is
found.
(link_symbol_table): Pass new arg to found_class.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcc&r1=1.110&r2=1.111
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/link.cc.diff?cvsroot=gcc&r1=1.13&r2=1.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3578&r2=1.3579
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&r1=1.83&r2=1.84



-- 


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

[Bug c++/16042] [3.3/3.4 regression] ICE with array assignment

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:36 ---
This is invalid code, so removed rejects-valid marker.

-- 
   What|Removed |Added

   Keywords|ice-on-valid-code, rejects- |ice-on-invalid-code
   |valid, wrong-code   |


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

[Bug target/16649] [3.4 Regression] bootstrap of gcc3.4.x fails on OpenDarwin7.2.1/x86

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:38 ---
Removing target milestone; OpenDarwin is not a primary or secondary target.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:38 ---
Subject: Bug 21144

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-29 18:38:44

Modified files:
gcc: ChangeLog postreload.c 

Log message:
PR rtl-optimization/21144
* postreload.c (reload_cse_move2add): Check for VOIDmode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.204&r2=2.7592.2.205
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/postreload.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.27&r2=2.27.8.1



-- 


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

[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:39 ---
Subject: Bug 21144

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:39:23

Modified files:
gcc: ChangeLog postreload.c 

Log message:
PR rtl-optimization/21144
* postreload.c (reload_cse_move2add): Check for VOIDmode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8532&r2=2.8533
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/postreload.c.diff?cvsroot=gcc&r1=2.29&r2=2.30



-- 


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

[Bug libgcj/21136] [4.0 only] tryLock waits for the lock, and lock doesn't

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:40 ---
Subject: Bug 21136

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-29 18:40:00

Modified files:
libjava: ChangeLog 
libjava/gnu/java/nio/channels: FileChannelImpl.java 

Log message:
2005-04-26  Luca Barbieri  <[EMAIL PROTECTED]>

PR libgcj/21136:
* gnu/java/nio/channels/FileChannelImpl.java (tryLock): Pass
'false' to native lock().
(lock): Pass 'true' to native lock().

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.55&r2=1.3391.2.56
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/nio/channels/FileChannelImpl.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.7.4.1&r2=1.7.4.2



-- 


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

[Bug libgcj/21136] [4.0 only] tryLock waits for the lock, and lock doesn't

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-04-29 
18:41 ---
I checked this in on the 4.0 branch.
It will appear in 4.0.1.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug java/19285] Interfaces not initialized by static field access

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:42 ---
Subject: Bug 19285

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:42:50

Modified files:
gcc/java   : java-tree.h expr.c decl.c class.c constants.c 
 ChangeLog 

Log message:
2005-04-28  Andrew Haley  <[EMAIL PROTECTED]>

PR java/19285
* java-tree.h (soft_resolvepoolentry_node): New.
(alloc_constant_fieldref): Declare.
* expr.c (expand_java_field_op): Don't call class_init for
accesses to static fields with indirect dispatch.
* builtins.c (initialize_builtins): Add "__builtin_expect".
* decl.c (soft_resolvepoolentry_node): New variable.
(java_init_decl_processing): Create a decl for
"_Jv_ResolvePoolEntry".
* class.c (build_fieldref_cache_entry): New function.
(build_static_field_ref): Rewrite for indirect dispatch.
* constants.c (find_name_and_type_constant_tree): New function.
(alloc_constant_fieldref): Likewise.
(build_constants_constructor): Handle CONSTANT_Fieldref and
CONSTANT_NameAndType.

PR java/21115
* expr.c (force_evaluation_order): Convert outgoing args smaller
than integer.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcc&r1=1.229&r2=1.230
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.222&r2=1.223
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&r1=1.218&r2=1.219
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.224&r2=1.225
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/constants.c.diff?cvsroot=gcc&r1=1.40&r2=1.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1601&r2=1.1602



-- 


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

[Bug java/21115] false boolean argument passed from pre-compiled to interpreted method is true

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:42 ---
Subject: Bug 21115

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:42:50

Modified files:
gcc/java   : java-tree.h expr.c decl.c class.c constants.c 
 ChangeLog 

Log message:
2005-04-28  Andrew Haley  <[EMAIL PROTECTED]>

PR java/19285
* java-tree.h (soft_resolvepoolentry_node): New.
(alloc_constant_fieldref): Declare.
* expr.c (expand_java_field_op): Don't call class_init for
accesses to static fields with indirect dispatch.
* builtins.c (initialize_builtins): Add "__builtin_expect".
* decl.c (soft_resolvepoolentry_node): New variable.
(java_init_decl_processing): Create a decl for
"_Jv_ResolvePoolEntry".
* class.c (build_fieldref_cache_entry): New function.
(build_static_field_ref): Rewrite for indirect dispatch.
* constants.c (find_name_and_type_constant_tree): New function.
(alloc_constant_fieldref): Likewise.
(build_constants_constructor): Handle CONSTANT_Fieldref and
CONSTANT_NameAndType.

PR java/21115
* expr.c (force_evaluation_order): Convert outgoing args smaller
than integer.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcc&r1=1.229&r2=1.230
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.222&r2=1.223
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&r1=1.218&r2=1.219
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.224&r2=1.225
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/constants.c.diff?cvsroot=gcc&r1=1.40&r2=1.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1601&r2=1.1602



-- 


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

[Bug java/19285] Interfaces not initialized by static field access

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:43 ---
Subject: Bug 19285

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:43:25

Modified files:
gcc/java   : builtins.c 

Log message:
2005-04-28  Andrew Haley  <[EMAIL PROTECTED]>

PR java/19285
* java-tree.h (soft_resolvepoolentry_node): New.
(alloc_constant_fieldref): Declare.
* expr.c (expand_java_field_op): Don't call class_init for
accesses to static fields with indirect dispatch.
* builtins.c (initialize_builtins): Add "__builtin_expect".
* decl.c (soft_resolvepoolentry_node): New variable.
(java_init_decl_processing): Create a decl for
"_Jv_ResolvePoolEntry".
* class.c (build_fieldref_cache_entry): New function.
(build_static_field_ref): Rewrite for indirect dispatch.
* constants.c (find_name_and_type_constant_tree): New function.
(alloc_constant_fieldref): Likewise.
(build_constants_constructor): Handle CONSTANT_Fieldref and
CONSTANT_NameAndType.

PR java/21115
* expr.c (force_evaluation_order): Convert outgoing args smaller
than integer.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/builtins.c.diff?cvsroot=gcc&r1=1.29&r2=1.30



-- 


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

[Bug java/21115] false boolean argument passed from pre-compiled to interpreted method is true

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:43 ---
Subject: Bug 21115

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:43:25

Modified files:
gcc/java   : builtins.c 

Log message:
2005-04-28  Andrew Haley  <[EMAIL PROTECTED]>

PR java/19285
* java-tree.h (soft_resolvepoolentry_node): New.
(alloc_constant_fieldref): Declare.
* expr.c (expand_java_field_op): Don't call class_init for
accesses to static fields with indirect dispatch.
* builtins.c (initialize_builtins): Add "__builtin_expect".
* decl.c (soft_resolvepoolentry_node): New variable.
(java_init_decl_processing): Create a decl for
"_Jv_ResolvePoolEntry".
* class.c (build_fieldref_cache_entry): New function.
(build_static_field_ref): Rewrite for indirect dispatch.
* constants.c (find_name_and_type_constant_tree): New function.
(alloc_constant_fieldref): Likewise.
(build_constants_constructor): Handle CONSTANT_Fieldref and
CONSTANT_NameAndType.

PR java/21115
* expr.c (force_evaluation_order): Convert outgoing args smaller
than integer.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/builtins.c.diff?cvsroot=gcc&r1=1.29&r2=1.30



-- 


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

[Bug target/14532] [3.4 Regression] s390x internal compiler error: output_operand: Cannot decompose address.

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:48 ---
Removing target milestone; S390 is not a primary or secondary target.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug target/15535] [3.3/3.4 regression][sh-linux] ICE with -m4 -O2

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-29 
18:48 ---
Removing target milestone; SH is not a primary or secondary target.

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:50 ---
Subject: Bug 21238

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:50:01

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/bits: locale_facets.tcc 
libstdc++-v3/testsuite: testsuite_character.cc 
testsuite_character.h 
Added files:
libstdc++-v3/testsuite/22_locale/num_get: 3.cc 
libstdc++-v3/testsuite/22_locale/num_put: 3.cc 
libstdc++-v3/testsuite/22_locale/money_get: 3.cc 
libstdc++-v3/testsuite/22_locale/money_put: 3.cc 

Log message:
2005-04-29  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/21238
* include/bits/locale_facets.tcc (num_get::_M_extract_float,
num_get::_M_extract_int, num_get::do_get(bool&),
num_put::_M_insert_int, num_put::_M_insert_float,
num_put::do_put(bool), money_get::_M_extract,
money_put::_M_insert): Adjust the __cache_type typedef not to
forward to a numpunct/moneypunct typedef.
* testsuite/testsuite_character.h: Add pod_uint and its numpunct
and moneypunct specializations.
* testsuite/testsuite_character.cc: Add numpunct::id
and moneypunct::id.
* testsuite/22_locale/num_get/3.cc: New.
* testsuite/22_locale/num_put/3.cc: Likewise.
* testsuite/22_locale/money_get/3.cc: Likewise.
* testsuite/22_locale/money_put/3.cc: Likewise.

* include/bits/locale_facets.tcc (money_put::_M_insert,
time_get::_M_extract_name): Prefer operator== to operator!=
on char_types.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2985&r2=1.2986
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/locale_facets.tcc.diff?cvsroot=gcc&r1=1.214&r2=1.215
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_character.cc.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_character.h.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/num_get/3.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/num_put/3.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/money_get/3.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/money_put/3.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-29 
18:51 ---
Fixed.  Add the PR number too.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/21272] SSA_NAME def follows use with -ftree-vectorize

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:52 ---
Subject: Bug 21272

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:51:58

Modified files:
gcc: ChangeLog 

Log message:
2005-04-29  Devang Patel  <[EMAIL PROTECTED]>

PR tree-optimization/21272
PR tree-optimization/21266
* tree-if-conv.c (find_phi_replacement_condition): Fix think-o.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8533&r2=2.8534



-- 


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-29 
18:52 ---
Subject: Bug 21266

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-29 18:51:58

Modified files:
gcc: ChangeLog 

Log message:
2005-04-29  Devang Patel  <[EMAIL PROTECTED]>

PR tree-optimization/21272
PR tree-optimization/21266
* tree-if-conv.c (find_phi_replacement_condition): Fix think-o.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8533&r2=2.8534



-- 


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

[Bug middle-end/21282] Converting floor into lfloor built-in function

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-04-29 18:56 
---
Hm, this should be fixed by a fix for PR21004:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00794.html.

If I understand correctly, the problem is shown only with newlib. Does newlib
set TARGET_C99_FUNCTIONS?

-- 


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

[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload

[matz at suse dot de]

--- Additional Comments From matz at suse dot de  2005-04-29 19:03 ---
This is now fixed, but it seems, even though I'm logged in, I can't change the 
state 
of this report. 

-- 


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

[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload

[pinskia at gcc dot gnu dot org]

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

(In reply to comment #7)
> This is now fixed, but it seems, even though I'm logged in, I can't change 
> the state 
> of this report. 

I will get you admin. access.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/21288] bootstrap issues with profiledbootstrap

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build, ice-on-valid-code
Summary|fortran bootstrap issues|bootstrap issues with
   ||profiledbootstrap


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

[Bug tree-optimization/21289] New: A numeric range is spoiled by a symblic one in VRP

[kazu at cs dot umass dot edu]

Consider

int
foo (int a, int b)
{
  if (a == 1)
if (a < b)
  if (a == 1)
return 1;

  return 0;
}

VRP does not remove the third "if" even though 'a' is known to be 1.

This is because the symbolic range obtained from the second "if"
spoils the numeric range [1, 1] obtained from the first "if".

extract_range_from_assert tries to refine a range from an ASSERT_EXPR
if there is another range previously available, but in this case,
VRP cannot prove that [1,1] and [-INF, b-1] intersects,
it does not refine a range.

-- 
   Summary: A numeric range is spoiled by a symblic one in VRP
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org


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