[Bug fortran/21375] Rising run-time errors at DEALLOCATE with STAT clause

[naf at naf dot net dot ru]

--- Additional Comments From naf at naf dot net dot ru  2005-05-04 05:58 
---
Tested with GNU F95 version 4.1.0 20050502 (experimental) (i386-linux)

-- 


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

[Bug fortran/21375] Rising run-time errors at DEALLOCATE with STAT clause

[naf at naf dot net dot ru]

--- Additional Comments From naf at naf dot net dot ru  2005-05-04 05:57 
---
Created an attachment (id=8815)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8815&action=view)
Sample code


-- 


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

[Bug fortran/21375] New: Rising run-time errors at DEALLOCATE with STAT clause

[naf at naf dot net dot ru]

When errors happens in DEALLOCATE with STAT the run-time error rises instead
setting up STAT variable. For example, following code:

-
PROGRAM MAIN
INTEGER, POINTER :: foo
INTEGER IERR
DEALLOCATE(foo,STAT=IERR)
WRITE (*,*) IERR
END PROGRAM
-

fails with 'Fortran runtime error: Internal: Attempt to DEALLOCATE unallocated
memory.' instead of setting IERR.

This bug corresponds with #17792.

-- 
   Summary: Rising run-time errors at DEALLOCATE with STAT clause
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: naf at naf dot net dot ru
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux


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

[Bug rtl-optimization/10588] [PPC] i==0||j==0 should use cntlzw and srawi

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
04:28 ---
I have not looked at this for a long time now.

-- 
   What|Removed |Added

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


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

[Bug java/20309] gcjh needs a -force option

[fitzsim at redhat dot com]

--- Additional Comments From fitzsim at redhat dot com  2005-05-04 02:32 
---
Fixed on mainline.


-- 
   What|Removed |Added

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


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

[Bug middle-end/8081] ICE with variably sized types and nested functions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
02:30 ---
I also filed PR 21374 for a tree dumping ICE.

-- 
   What|Removed |Added

   Last reconfirmed|2005-05-04 02:26:07 |2005-05-04 02:30:45
   date||


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

[Bug tree-optimization/21374] New: ICE in declare_return_variable, at tree-inline.c:906

[pinskia at gcc dot gnu dot org]

This is a split off of PR8081 but is a different problem but this time with the 
tree dumper (I think), 
compile the following at -O2 -fdump-tree-all:
int
main (int argc, char **argv)
{
  int size = 10;
  int i;
  typedef struct
  {
char val[size];
  }
  block;
  block b;
  block retframe_block ()
  {
return *(block *) 0;
  }
  b=retframe_block ();
  return 0;
}

-- 
   Summary: ICE in declare_return_variable, at tree-inline.c:906
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug bootstrap/21365] libiberty/regex.c:49:25: error: sys/types.h: No such file or directory

[yuri_you2003 at yahoo dot com]

--- Additional Comments From yuri_you2003 at yahoo dot com  2005-05-04 
02:29 ---
Subject: Re:  libiberty/regex.c:49:25: error: sys/types.h: No such file or 
directory

What is a combined build?

--- pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> 
> --- Additional Comments From pinskia at gcc dot
> gnu dot org  2005-05-04 01:27 ---
> (In reply to comment #2)
> 
> Oh you need to do a combine build.
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21365
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


-- 


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

[Bug tree-optimization/17046] An unused array is not optimized away.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
02:16 ---
Fixed for 4.1.0, most likely by the patches by Jan Honza.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/14841] [tree-ssa] const_array[CST] is not folded

[pinskia at gcc dot gnu dot org]

-- 
Bug 14841 depends on bug 17046, which changed state.

Bug 17046 Summary: An unused array is not optimized away.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17046

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/15618] Missed bool optimization

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-04 
01:52 ---
Subject: Bug 15618

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-04 01:52:07

Modified files:
gcc: ChangeLog fold-const.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/tree-ssa: bool-1.c bool-2.c bool-3.c 
   bool-4.c bool-5.c bool-6.c 
   bool-7.c bool-8.c bool-9.c 

Log message:
2004-05-03  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/15618
* fold-const.c (fold_widened_comparison): Treat BOOLEAN_TYPE
the same as INTEGER_TYPE.
(fold_binary): Fold "bool_var != 0" to bool_var.
Fold "bool_var == 1" to bool_var.
2005-05-03  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/15618
* gcc.dg/tree-ssa/bool-[1-9].c: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8592&r2=2.8593
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.573&r2=1.574
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5438&r2=1.5439
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-5.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-6.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-7.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-8.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/bool-9.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/18908] Missed folding opportunities with bools

[pinskia at gcc dot gnu dot org]

-- 
Bug 18908 depends on bug 15618, which changed state.

Bug 15618 Summary: Missed bool optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15618

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/15017] [tree-ssa] compare (equal) with casts are not removed

[pinskia at gcc dot gnu dot org]

-- 
Bug 15017 depends on bug 15618, which changed state.

Bug 15618 Summary: Missed bool optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15618

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[pinskia at gcc dot gnu dot org]

-- 
Bug 15826 depends on bug 15618, which changed state.

Bug 15618 Summary: Missed bool optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15618

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[pinskia at gcc dot gnu dot org]

-- 
Bug 19987 depends on bug 15618, which changed state.

Bug 15618 Summary: Missed bool optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15618

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/15618] Missed bool optimization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
01:52 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/14442] [tree-ssa] missed sib if conversion optimization on the tree level

[pinskia at gcc dot gnu dot org]

-- 
Bug 14442 depends on bug 15618, which changed state.

Bug 15618 Summary: Missed bool optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15618

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments

[pinskia at gcc dot gnu dot org]

-- 
Bug 19719 depends on bug 15618, which changed state.

Bug 15618 Summary: Missed bool optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15618

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug java/20309] gcjh needs a -force option

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-04 
01:46 ---
Subject: Bug 20309

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-04 01:46:42

Modified files:
gcc/java   : ChangeLog Make-lang.in config-lang.in gcj.texi 
 gjavah.c 

Log message:
2005-05-03  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

PR java/20309
* Make-lang.in (java): Add gjnih.
(JAVA_TARGET_INDEPENDENT_BIN_TOOLS): Likewise.
(GJNIH_OBJS): New variable.
(gjnih$(exeext)): New target.
(JAVA_MANFILES): Add gjnih.1.
(java.uninstall): Add gjnih.1.
(java.mostlyclean): Add gjnih.
(java.maintainer-clean): Add gjnih.1.
(java/gjavah-jni.o): New target.
(.INTERMEDIATE): Add gjnih.pod.
(gjnih.pod): New target.
* config-lang.in (stagestuff): Add gjnih.
* gcj.texi (Top): Add gjnih node.
(Invoking gcjh): Add descriptions of -force, -old, -trace, -J and
-bootclasspath options.
(Invoking gjnih): New node.
* gjavah.c Initialize flag_jni to 1 if JNI_DEFAULT is defined.
(TOOLNAME): New macro.
(error): Replace hard-coded gcjh with TOOLNAME.
(process_file): Likewise.
(usage): Likewise.
(version): Likewise.
(help): Likewise.  Add help output for -force, -old, -trace and -J
options.
(OPT_FORCE, OPT_OLD, OPT_TRACE): New macros.
(options): Add force, old, trace and J fields.
(main): Handle -force, -old, -trace and -J options.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1606&r2=1.1607
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/Make-lang.in.diff?cvsroot=gcc&r1=1.157&r2=1.158
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/config-lang.in.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gcj.texi.diff?cvsroot=gcc&r1=1.83&r2=1.84
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gjavah.c.diff?cvsroot=gcc&r1=1.131&r2=1.132



-- 


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

[Bug middle-end/21318] [4.1 Regression] ICE in instantiate_virtual_regs_in_insn

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug middle-end/21318] [4.1 Regression] ICE in instantiate_virtual_regs_in_insn

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-04 01:39 
---
Fixed, I assume.  Reopen if not.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/21318] [4.1 Regression] ICE in instantiate_virtual_regs_in_insn

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-04 
01:38 ---
Subject: Bug 21318

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-04 01:38:14

Modified files:
gcc: ChangeLog function.c 

Log message:
PR middle-end/21318
* function.c (instantiate_virtual_regs_in_insn): Use the mode
from recog_data instead of insn_data.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8591&r2=2.8592
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.619&r2=1.620



-- 


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

[Bug bootstrap/21365] libiberty/regex.c:49:25: error: sys/types.h: No such file or directory

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
01:27 ---
(In reply to comment #2)

Oh you need to do a combine build.

-- 


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

[Bug middle-end/21360] [3.4/4.0/4.1 Regression] wrong result of 'if' statement with comparing of floating point with gcc.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor


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

[Bug target/21316] [3.4 Regression] pointer lookup cache misses more frequent

[kpmassey at gmail dot com]

--- Additional Comments From kpmassey at gmail dot com  2005-05-04 01:20 
---
Subject: Re:  [3.4 Regression] pointer lookup cache misses more frequent

Actually, no.  Gentoo doesn't yet have 4.0.0 in portage, and being a
novice, I am reluctant to build myself.

On 4 May 2005 01:16:33 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
> 01:16 ---
> I could not reproduce this on a pentium4.
> 
> --
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug target/21316] [3.4 Regression] pointer lookup cache misses more frequent

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 
01:16 ---
I could not reproduce this on a pentium4.

-- 


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

[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-04 
01:16 ---
PRE should notice the value is AVAIL in the block it's placing it in, so it
shouldn't end up in the insert bitmap.


-- 


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

Re: Gcc 4.0.0 on NCR

[James E Wilson]

Bruzzone Mirko wrote:
make: fatal error: don't know how to make ./../include/ansidecl.h (bu42).
*** Error code 1 (bu21)
Are you building in the srcdir or a separate objdir?  Building in the 
srcdir is supposed to work, but is known to be broken in gcc-4.0.0.  So 
you must build in a separate objdir.  E.g.
  mkdir objdir
  cd objdir
  ../gcc-4.0.0/configure ...

Are you using GNU make?  The gcc makefile requires a recent version of 
GNU make.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2005-03-30 10:00:18 |2005-05-04 01:05:07
   date||


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

[Bug other/21328] bogus permissions on files in CVS

[ian at airs dot com]

--- Additional Comments From ian at airs dot com  2005-05-04 00:57 ---
Fixed in the CVS repository.  Should now be fixed for people who check out a
fresh working directory.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/21316] [3.4 Regression] pointer lookup cache misses more frequent

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-04 
00:16 ---
Can you try with 4.0.0?

-- 
   What|Removed |Added

Summary|pointer lookup cache misses |[3.4 Regression] pointer
   |more frequent   |lookup cache misses more
   ||frequent
   Target Milestone|--- |3.4.4


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

[Bug libstdc++/21371] Segmentation violation for repeated calls of destrictor for STL container

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-04 
00:08 ---
Both.

-- 


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

[Bug libgcj/8995] race cases in interpreter

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-03 
23:17 ---
FWIW that patch has long since gone missing :-(

Perhaps this problem can most easily be solved using the
new __sync built-ins.


-- 


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

[Bug tree-optimization/20742] [4.0 Regression] Hang in tree_ssa_iv_optimize_loop

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
23:05 ---
Subject: Bug 20742

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-05-03 23:05:32

Modified files:
gcc: ChangeLog Makefile.in params.def tree-chrec.c 
 tree-chrec.h tree-scalar-evolution.c 
gcc/doc: invoke.texi 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050423-1.c 

Log message:
2005-05-04  Sebastian Pop  <[EMAIL PROTECTED]>

PR tree-optimization/20742
* Makefile.in (tree-chrec.o): Depend on params.h.
* params.def (PARAM_SCEV_MAX_EXPR_SIZE): New parameter with
default value 20.
* tree-chrec.c: Depend on params.h.  Replace build with buildN.
(chrec_fold_plus_1): Fail with a chrec_don_know when the size of
the expression exceeds PARAM_SCEV_MAX_EXPR_SIZE.
(tree_contains_chrecs): Compute an estimation of the size of the
given expression.
* tree-chrec.h (tree_contains_chrecs): Modify its declaration.
(tree_does_not_contain_chrecs): Update the use of tree_contains_chrecs.
* tree-scalar-evolution.c (simple_iv): Ditto.
* doc/invoke.texi (scev-max-expr-size): Documented.

2005-05-04  Jakub Jelinek  <[EMAIL PROTECTED]>

PR tree-optimization/20742
* gcc.c-torture/compile/20050423-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=2.7592.2.10.2.27&r2=2.7592.2.10.2.28
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.1447.4.4&r2=1.1447.4.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.54.8.1&r2=1.54.8.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=2.12.14.2&r2=2.12.14.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=2.6&r2=2.6.16.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=2.17.6.1&r2=2.17.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.583.2.1.2.10&r2=1.583.2.1.2.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.5084.2.9.2.22&r2=1.5084.2.9.2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050423-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug middle-end/21285] gij fails to handle NullPointerException exception

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-03 23:03 ---
Ok, somehow generic exception handler is missed on linux alpha. At this point I
don't undestand how and leave it for professionals.

Just check the same test on:
gij (GNU libgcj) version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)

The output is:
gij Test
Exception in thread "main" java.lang.NullPointerException
   at Test.main(java.lang.String[]) (Unknown Source)

Thank you.

-- 


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

[Bug target/21098] .note.GNU-stack emitted

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
23:03 ---
Subject: Bug 21098

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-05-03 23:02:54

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: linux64.h rs6000.c 

Log message:
Revert:
2005-04-29  Alan Modra  <[EMAIL PROTECTED]>
PR target/21098
* config/rs6000/rs6000.c (rs6000_elf_end_indicate_exec_stack): New.
* config/rs6000/linux64.h (TARGET_ASM_FILE_END): Use the above.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=2.7592.2.10.2.26&r2=2.7592.2.10.2.27
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/linux64.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.74.12.1&r2=1.74.12.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-rhl-branch&r1=1.788.4.8&r2=1.788.4.9



-- 


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-03 
22:48 ---
I checked in the fix to the trunk, the 4.0 branch, and Classpath.
Thanks for the clear test case and patch.


-- 
   What|Removed |Added

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


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
22:47 ---
Subject: Bug 21372

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-03 22:47:13

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

Log message:
2005-05-03  Andrew Overholt  <[EMAIL PROTECTED]>

PR libgcj/21372:
* gnu/java/nio/channels/FileChannelImpl.java: Return null if lock
could not be acquired.
* java/nio/channels/FileLock.java (toString): Re-implement to be
in line with other implementations.

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.56&r2=1.3391.2.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/channels/FileLock.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4&r2=1.4.40.1
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.2&r2=1.7.4.3



-- 


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

[Bug c++/14179] [3.3/3.4/4.0/4.1 Regression] out of memory while parsing array with many initializers

[debora dot j dot estey at lmco dot com]

--- Additional Comments From debora dot j dot estey at lmco dot com  
2005-05-03 22:44 ---
any word on this?

-- 


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

[Bug libstdc++/21371] Segmentation violation for repeated calls of destrictor for STL container

[john dot e dot bussoletti at boeing dot com]

--- Additional Comments From john dot e dot bussoletti at boeing dot com  
2005-05-03 22:39 ---
(In reply to comment #1)
> This is undefined so a seg fault is okay.


Which part is undefined, the invocation of member functions of an object for 
which a destructor has been called (this part works correctly), or the multiple 
calls of the destructor of a class (this fails in 64 bit OS but runs without 
complaint in 32 bit OS)?




-- 


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

[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-05-03 22:39 ---
Subject: Re:  [4.1 Regression] Link error: unsatisfied symbols

> --- Additional Comments From neroden at gcc dot gnu dot org  2005-05-03 
> 01:33 ---
> I'm waiting for feedback here; because this is a port-specific proble I can't
> test fixes on my own.  Patch in bug trail.

The patch resolves the link error.

Thanks,
Dave


-- 


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

[Bug libfortran/20930] [4.0/4.1 Regression] gfortran.dg/backspace.f execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-05-03 22:39 ---
Subject: Re:  [4.0/4.1 Regression] gfortran.dg/backspace.f execution test

> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
> 18:24 ---
> (In reply to comment #7)
> > John, does this work now?
> Ping,

Yes.  See .

Dave


-- 


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
22:38 ---
Subject: Bug 21372

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-03 22:38:17

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

Log message:
2005-05-03  Andrew Overholt  <[EMAIL PROTECTED]>

PR libgcj/21372:
* gnu/java/nio/channels/FileChannelImpl.java: Return null if lock
could not be acquired.
* java/nio/channels/FileLock.java (toString): Re-implement to be
in line with other implementations.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3584&r2=1.3585
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/channels/FileLock.java.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/nio/channels/FileChannelImpl.java.diff?cvsroot=gcc&r1=1.10&r2=1.11



-- 


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

[Bug other/21328] bogus permissions on files in CVS

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||overseers at gcc dot gnu dot
   ||org


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

[Bug libstdc++/21371] Segmentation violation for repeated calls of destrictor for STL container

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
22:34 ---
This is undefined so a seg fault is okay.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution||INVALID


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

[Bug middle-end/21265] [4.0/4.1 regression] GCC fails to optimize tail call to memset

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
22:22 ---
Subject: Bug 21265

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-03 22:22:02

Modified files:
gcc: ChangeLog expr.h expr.c builtins.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: 20050503-1.c 

Log message:
PR middle-end/21265
* expr.h (enum block_op_methods): Add BLOCK_OP_TAILCALL.
(clear_storage): Add argument.
* expr.c (emit_block_move_via_libcall, clear_storage_via_libcall):
Add tailcall argument, set CALL_EXPR_TAILCALL of the CALL_EXPR to
tailcall.
(emit_block_move): Handle BLOCK_OP_TAILCALL method.
(clear_storage): Add method argument, handle BLOCK_OP_TAILCALL.
(store_expr, store_constructor): Adjust callers.
* builtins.c (expand_builtin_memcpy): Pass BLOCK_OP_TAILCALL
to emit_block_move if CALL_EXPR_TAILCALL (exp).
(expand_builtin_memmove): Add ORIG_EXP argument, copy
CALL_EXPR_TAILCALL from ORIG_EXP to the new CALL_EXPR.
(expand_builtin_bcopy): Replace ARGLIST and TYPE arguments
with EXP.  Pass EXP to expand_builtin_memmove.
(expand_builtin_memset): Add ORIG_EXP argument, pass
BLOCK_OP_TAILCALL to clear_storage if CALL_EXPR_TAILCALL (orig_exp).
(expand_builtin_bzero): Replace ARGLIST argument with EXP.
Pass EXP to expand_builtin_memset.
(expand_builtin_strcmp): Copy CALL_EXPR_TAILCALL from EXP to
the new CALL_EXPR.
(expand_builtin_strncmp): Likewise.
(expand_builtin_printf): Replace ARGLIST argument with EXP.
Copy CALL_EXPR_TAILCALL from EXP to the new CALL_EXPR.
(expand_builtin_fprintf): Likewise.
(expand_builtin): Adjust calls to
expand_builtin_{memmove,bcopy,memset,bzero,{,f}printf}.

* gcc.dg/20050503-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8588&r2=2.8589
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.h.diff?cvsroot=gcc&r1=1.187&r2=1.188
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.788&r2=1.789
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&r1=1.460&r2=1.461
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5437&r2=1.5438
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050503-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug libgcj/21326] seg fault in _Jv_Linker

[rspencer at x10sys dot com]

--- Additional Comments From rspencer at x10sys dot com  2005-05-03 22:16 
---
I don't see how that is possible on the application side as the source code is
100% Java and it is all compiled with the same options (there's only one
compilation command that compiles all sources). Perhaps you are suggesting that
libgcj is compiled differently from the application?  If so, shouldn't the
default compilation flags automatically work correctly with libgcj? The only
flags given are "-g -02".

So, I tried your suggestion. I compiled JING with HotSpot 1.4.2. It compiled
fine to .class files via javac 1.4.2.  I compiled the .class files (one command
line again) with GCJ using the -findirect-dispatch option. GCJ gave hundreds of
errors. Most of the errors were about "finalized field 'xyz' may not have been
initialized".  That sounds more like a warning to me, but I wouldn't know. I
take it that GCJ doesn't like foreign compiled .class files?

I'm not sure where to go from here except to give up on GCJ. Any other 
suggestions?

-- 


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

[Bug rtl-optimization/21239] [4.0/4.1 Regression] Illegal elimination of SSE2 load/store using xmm intrinsics

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
22:16 ---
Subject: Bug 21239

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-03 22:16:02

Modified files:
gcc: ChangeLog combine.c 
gcc/testsuite  : ChangeLog 
gcc/config/i386: i386.c 
Added files:
gcc/testsuite/gcc.dg: i386-sse-11.c 

Log message:
* config/i386/i386.c (ix86_expand_vector_set): Fix setting 3rd and 4th
item in V4SF mode.

PR rtl-optimization/21239
* combine.c (combine_simplify_rtx) : Fix a typo.

* gcc.dg/i386-sse-11.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8587&r2=2.8588
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&r1=1.488&r2=1.489
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5436&r2=1.5437
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.817&r2=1.818
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/i386-sse-11.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/21367] VRP does not fold "if (a == b)" in a certain situation

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
22:11 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-03 22:11:52
   date||


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

[Bug tree-optimization/21368] VRP does not know that &s.a != NULL

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
22:11 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-03 22:11:03
   date||


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

[Bug java/21245] gcjh creates invalid/empty header files

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-05-03 21:57 
---
There is already a ChangeLog entry with the patch

-- 


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
21:56 ---
(In reply to comment #5)
> This patch looks good to me.
> Could you write a ChangeLog entry for it?
He did in 

Confirmed,

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/java-
   ||patches/2005-
   ||q2/msg00371.html
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2005-05-03 21:56:01
   date||


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

[Bug fortran/21370] gfortran: TARGET attribute for dummy argument and declaration order

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
21:54 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-05-03 21:54:24
   date||


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-03 
21:54 ---
This patch looks good to me.
Could you write a ChangeLog entry for it?


-- 


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

[Bug target/18759] [x86] using both -fomit-frame-pointer and -momit-leaf-frame-pointer enables frame pointers for non-leaf functions

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
21:54 ---
Subject: Bug 18759

CVSROOT:/cvs/gcc
Module name:gcc
Branch: csl-sol210-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-05-03 21:54:14

Modified files:
.  : ChangeLog.csl 
gcc/config/i386: i386.c 

Log message:
Backport from mainline:
2004-12-02  Roger Sayle  <[EMAIL PROTECTED]>

PR target/18759
* config/i386/i386.c (override_options): If -fomit-frame-pointer has
already been specified, ignore the -momit-leaf-frame-pointer option.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.csl.diff?cvsroot=gcc&only_with_tag=csl-sol210-3_4-branch&r1=1.1.2.16&r2=1.1.2.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=csl-sol210-3_4-branch&r1=1.635.2.15.2.2&r2=1.635.2.15.2.3



-- 


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

[Bug middle-end/21285] gij fails to handle NullPointerException exception

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
21:51 ---
Hmm, maybe this is not a bug in libgcj and in the middle-end related to EH.

-- 
   What|Removed |Added

  Component|libgcj  |middle-end
   Keywords||EH, wrong-code


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-03 21:49 ---
So far I was able to debug to interpret.cc:3211.
It seems that unwind logic worked correctly (as far as I could understand) and
catch handler was called. The logic here didn't find exception handler and
"thrown" exception again that lead to "abort" (since no more handlers were 
found).

I am going to recompile interpret.cc without optimization and check again if my
assumptions are true. Could DIRECT_THREADED define doesn't work on alpha linux?

-- 


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

[Bug c++/21165] [4.0/4.1 Regression] bogus error on a user-defined conversion in a template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
21:44 ---
*** Bug 21373 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||pkoning at equallogic dot
   ||com


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

[Bug c++/21373] [4.0/4.1 Regression] Strange error message on reference to static const member initialized via cast

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
21:44 ---
Confirmed:
t.cc: In member function âbool foo::toobig(long long unsigned int)â:
t.cc:7: internal compiler error: tree check: expected record_type or 
union_type or qual_union_type, have template_type_parm in lookup_conversions, 
at cp/search.c:2407
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


But this is a dup of bug 21165.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-checking, ice-on-valid-
   ||code, rejects-valid
 Resolution||DUPLICATE
Summary|Strange error message on|[4.0/4.1 Regression] Strange
   |reference to static const   |error message on reference
   |member initialized via cast |to static const member
   ||initialized via cast
   Target Milestone|--- |4.0.1


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[overholt at redhat dot com]

--- Additional Comments From overholt at redhat dot com  2005-05-03 21:44 
---
Created an attachment (id=8813)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8813&action=view)
patch


-- 


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

[Bug c++/21373] New: Strange error message on reference to static const member initialized via cast

[pkoning at equallogic dot com]

Test program:

template  class foo
{
public:
static const unsigned long long max = (T)~0ULL;
bool toobig (unsigned long long val) 
{
return val > max;
}
};

Message:

test.cc: In member function ‘bool foo::toobig(long long unsigned int)’:
test.cc:7: error: ‘T’ used where a ‘long long unsigned int’ was expected

The baffling part is that T doesn't occur anywhere in or near line 7.  It's
almost as if the initialization part of the static const member has been
textually substituted in line 7 -- but if it were that should still be legal... 

It works ok if I explicitly initialize the member outside the class definition
via specializations, which is tolerable given that only a small number of cases
of this template class are used.

-- 
   Summary: Strange error message on reference to static const
member initialized via cast
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
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=21373

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[overholt at redhat dot com]

--- Additional Comments From overholt at redhat dot com  2005-05-03 21:29 
---
Created an attachment (id=8812)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8812&action=view)
second part to the test case

Run this while TestLocking2 is running.

-- 


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[overholt at redhat dot com]

--- Additional Comments From overholt at redhat dot com  2005-05-03 21:28 
---
Created an attachment (id=8811)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8811&action=view)
test case part 1

Run this file and leave it running while you try to run the second attachment
(forthcoming).

-- 
   What|Removed |Added

Attachment #8810 is|0   |1
   obsolete||


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

[Bug libgcj/21372] FileChannel.tryLock() return value incorrect

[overholt at redhat dot com]

--- Additional Comments From overholt at redhat dot com  2005-05-03 21:24 
---
Created an attachment (id=8810)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8810&action=view)
test case part 1

Run this part first.

-- 


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

[Bug libgcj/21372] New: FileChannel.tryLock() return value incorrect

[overholt at redhat dot com]

According to the spec, FileChannel.tryLock() should return null in the event
that it cannot acquire a lock.  libgcj's implementation does not currently do
this and returns a FileLock object even though the lock has not been acquired. 
See attached test case.

-- 
   Summary: FileChannel.tryLock() return value incorrect
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: overholt at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug c++/21371] New: Segmentation violation for repeated calls of destrictor for STL container

[john dot e dot bussoletti at boeing dot com]

The sample code runs differently in 32 bit (g++ 3.2-7) and 64 bit (g++ 3.2.3-49)
versions of the compiler.  I'm not sure which behavior is correct, but both
version of the compiler yield information on the vector  A entity via calls
to A.size() and A.capacity() calls.  I would have expected a bomb at that point.
 The 32 bit compiler treats the call to the destructor at the close of the main
program gracefully and exits normally. The 64 bit version aborts on a segment
violation, creating a core file.  It appears that any attempt to explicity call
a destructor for a STL entity causes an abort on the 64 bit systems when the
compiler-generated call to the destructor is called at the end of scope.  This
behavior is different on the 32 bit compiler version.  

Which is correct behavior?

Sample code follows:
#include 
#include 
#include 

using namespace std;

int main()
{

int i = 1;
vector < int > A;

cout << "Created vector entity " << endl;
cout << " Entity size " << A.size() << endl;
cout << " Entity capacity " << A.capacity() << endl;
A.assign( 1000, 1);
cout << "After assign call " << endl;
cout << " Entity size " << A.size() << endl;
cout << " Entity capacity " << A.capacity() << endl;
A.clear();
cout << "After clear call " << endl;
cout << " Entity size " << A.size() << endl;
cout << " Entity capacity " << A.capacity() << endl;
A.reserve( 1 );
cout << "After reserve zero call " << endl;
cout << " Entity size " << A.size() << endl;
cout << " Entity capacity " << A.capacity() << endl;
A.resize( 1 , i);
cout << "After resize call " << endl;
cout << " Entity size " << A.size() << endl;
cout << " Entity capacity " << A.capacity() << endl;
A.~vector();
cout << "After destructor call " << endl;
cout << " Entity size " << A.size() << endl;
cout << " Entity capacity " << A.capacity() << endl;
   
}


Output from 32 bit OS, Linux 2.4.18-14smp, Red Hat Linux 8.0, gcc 3.2-7:
Created vector entity 
 Entity size 0
 Entity capacity 0
After assign call 
 Entity size 1000
 Entity capacity 1000
After clear call 
 Entity size 0
 Entity capacity 1000
After reserve zero call 
 Entity size 0
 Entity capacity 1000
After resize call 
 Entity size 1
 Entity capacity 1000
After destructor call 
 Entity size 1
 Entity capacity 1000

application terminates normally

Output from 64 bit g++ on Linux 2.4.21-27.0.1 Red Hat Linux 3.2.3, g++ version
3.2.3:
Created vector entity 
 Entity size 0
 Entity capacity 0
After assign call 
 Entity size 1000
 Entity capacity 1000
After clear call 
 Entity size 0
 Entity capacity 1000
After reserve zero call 
 Entity size 0
 Entity capacity 1000
After resize call 
 Entity size 1
 Entity capacity 1000
After destructor call 
 Entity size 1
 Entity capacity 1000
Segmentation fault (core dumped)

-- 
   Summary: Segmentation violation for repeated calls of destrictor
for STL container
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot e dot bussoletti at boeing dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/18759] [x86] using both -fomit-frame-pointer and -momit-leaf-frame-pointer enables frame pointers for non-leaf functions

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-03 21:04 
---
I'm backporting this patch to csl-sol210-3_4-branch.  In theory there's a
regression on vanilla 3.4 if you build pr9771-1.c with -momit-leaf-frame-pointer
in addition to the options specified in that testcase (then this bug causes it
to fail); it's just the Solaris 10 port which isn't in vanilla 3.4 which makes
this more visible by having -momit-leaf-frame-pointer on by default when 
optimizing.


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug java/21245] gcjh creates invalid/empty header files

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-03 
20:55 ---
I checked in a fix for this.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-03 20:54 ---
How could I check that?
I ran "make check" in libffi library and it has not produced any errors.


-- 


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

[Bug java/21245] gcjh creates invalid/empty header files

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
20:51 ---
Subject: Bug 21245

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-03 20:51:32

Modified files:
gcc/java   : ChangeLog gjavah.c 

Log message:
PR java/21245:
* gjavah.c (main): Unlink output file on error.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1605&r2=1.1606
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gjavah.c.diff?cvsroot=gcc&r1=1.130&r2=1.131



-- 


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

[Bug c++/21369] [4.0/4.1 Regression] Template function definition rejected if function return type begins with 'struct'

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
20:50 ---
Confirmed, it worked with "4.0.0 20041124" but not right before the branch of 
4.0.0.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-05-03 20:50:37
   date||
Summary|Template function definition|[4.0/4.1 Regression]
   |rejected if function return |Template function definition
   |type begins with 'struct'   |rejected if function return
   ||type begins with 'struct'
   Target Milestone|--- |4.0.1


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

[Bug fortran/21370] New: gfortran: TARGET attribute for dummy argument and declaration order

[anlauf at hep dot tu-darmstadt dot de]

Hi,

the following code fails to compile unless the two marked lines are 
interchanged:

subroutine gfcbug27 (x)
  real, intent(inout) :: x(:)

  real  :: tmp(size (x,1))  ! gfc produces an error unless
  target:: x! these 2 lines interchanged
  real, pointer :: p(:)

  p => x(:)
end subroutine gfcbug27


I get:

 In file gfcbug27.f90:5

  target:: x! these 2 lines interchanged
   1
Error: Cannot change attributes of symbol at (1) after it has been used
 In file gfcbug27.f90:8

  p => x(:)
  1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)

Cheers,
-ha

-- 
   Summary: gfortran: TARGET attribute for dummy argument and
declaration order
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anlauf at hep dot tu-darmstadt dot de
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=21370

[Bug c++/21369] New: Template function definition rejected if function return type begins with 'struct'

[pkoning at equallogic dot com]

This test program:

struct bar;

template  struct bar *foo (T *p)
{
return p->t;
}

produces an error in 4.0.0:

test.cc:3: error: 'bar' is not a template type

Without the keyword "struct" it compiles fine.  Earlier versions
(3.3.2, and I'm pretty sure 3.4.1 as well) don't complain.

I've seen this on a native Linux build, and also a crosscompiler targeted at
netbsd-mips and hosted on i386-mips.

-- 
   Summary: Template function definition rejected if function return
type begins with 'struct'
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
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=21369

[Bug tree-optimization/21357] Erroneous warning: " ... may be used uninitialized in this function"

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-03 20:20 
---
Not a C front end bug and previously reported more than once.


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |tree-optimization
 Resolution||DUPLICATE


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

[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-03 20:20 
---
*** Bug 21357 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||william at gallaf dot net


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

[Bug other/21322] O2 and O3 memory access error - compiled program - incorrect debug output

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-03 20:16 
---
Not a bug in the C front end.  The next step in tracking down the problem would
be to try compiling just one file with -O2, the rest with -O0, and find which
file being compiled with -O2 yields the problem.  Then split out the functions
from that file into separate files and see which function is being miscompiled.


-- 
   What|Removed |Added

  Component|c   |other


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

[Bug c/18502] [3.3/3.4 Regression] trigraphs don't work with -std=gnu99

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-03 20:04 
---
Fixed for 3.4.4.  Will not now be fixed on 3.3 branch.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/21365] libiberty/regex.c:49:25: error: sys/types.h: No such file or directory

[yuri_you2003 at yahoo dot com]

--- Additional Comments From yuri_you2003 at yahoo dot com  2005-05-03 
19:56 ---
Subject: Re:  libiberty/regex.c:49:25: error: sys/types.h: No such file or 
directory


The failure is not on the cygwin compiler,
I believe the missing headers are not part of the
standard gcc headers.

The gcc package compiles libiberty twice,
once in the directory ./libiberty using the gcc
from cygwin, and once in ./sh3-elf/libiberty,
in this second compilation it uses the xgcc compiler,
the executable was just build as part of the gcc
package. As such I would expect the headers to be
a part of the newly compiled gcc.

I can find the missing header file names in the source
directory 'fixincludes', but these headers do not go
anywhere, they just stay there. It seems there is
something wrong with the 'fixincludes' directory

--- pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> 
> --- Additional Comments From pinskia at gcc dot
> gnu dot org  2005-05-03 19:09 ---
> This area in the file has not changed in a while.
> I would assume it would be included with the
> standard headers.
> Anyways this is either a bug in cygwin's installer
> or your install of cygwin.
> 
> -- 
>What|Removed
> |Added
>

>  Status|UNCONFIRMED
> |RESOLVED
>  Resolution|   
> |WORKSFORME
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21365
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-03 
19:52 ---
Hmm, could it be that the libffi does not handle exceptions.

-- 
   What|Removed |Added

   Severity|critical|normal


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

[Bug libfortran/20744] [4.0 only] size= isn't implemented correctly

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:52 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[tkoenig at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 17992, which changed state.

Bug 17992 Summary: [4.0 only] reading empty line does not return 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/17992] [4.0 only] reading empty line does not return 0

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:51 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/20661] [4.0 only] End of record not detected

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:51 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/19595] [4.0 only] eor does not work

[tkoenig at gcc dot gnu dot org]

-- 
Bug 19595 depends on bug 20661, which changed state.

Bug 20661 Summary: [4.0 only] End of record not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20661

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/19595] [4.0 only] eor does not work

[tkoenig at gcc dot gnu dot org]

-- 
Bug 19595 depends on bug 19568, which changed state.

Bug 19568 Summary: [4.0 only] incorrect formatted read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/20661] [4.0 only] End of record not detected

[tkoenig at gcc dot gnu dot org]

-- 
Bug 20661 depends on bug 19568, which changed state.

Bug 19568 Summary: [4.0 only] incorrect formatted read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/19568] [4.0 only] incorrect formatted read

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:51 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/20108] [4.0 only] incorrect run time error on formatted read

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:49 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[tkoenig at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 20108, which changed state.

Bug 20108 Summary: [4.0 only] incorrect run time error on formatted read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20108

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/17992] [4.0 only] reading empty line does not return 0

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:49 ---
Patch committed to 4.0.1.  Fixed.

-- 


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

[Bug libfortran/20661] [4.0 only] End of record not detected

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:48 ---
Patch committed to 4.0.1.  Fixed.

-- 


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

[Bug libfortran/20131] [4.0 only] gfortan - incorrectly reads beyond the end of line.

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:47 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[tkoenig at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 20092, which changed state.

Bug 20092 Summary: [4.0 only] console input doesn't deal correctly with CR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/20092] [4.0 only] console input doesn't deal correctly with CR

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:47 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/20005] [4.0 only] reading a single "return" character fails

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:46 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-03 19:46 ---
Here is another stack dump from attempt of running the "ant":
exec "/usr/lib/jvm/java/bin/java" -classpath
"/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/jakarta-commons-logging.jar:/usr/share/java/ant/ant-commons-logging.jar:/usr/lib/jvm/java/lib/tools.jar:/usr/share/java/jdtcore.jar"
-Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib"
org.apache.tools.ant.launch.Launcher -lib ""

The "ra" member of context parameter has bad value, but how it got it ... I
could not trace.

This issue might not be related to original one, but it fails in unwind logic
too (so it could give more info).

My test case (and "ant") worked on gcc 3.4.3 version built on the environment.

If you need more info about my environment I would glad to tell.

Thank you.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2199023384624 (LWP 32406)]
0x020001886254 in alpha_fallback_frame_state (context=0x11f831c28,
fs=0x11f831e68) at ../../gcc/config/alpha/linux-unwind.h:45
45if (pc[0] != 0x47fe0410   /* mov $30,$16 */
(gdb) bt
#0  0x020001886254 in alpha_fallback_frame_state (context=0x11f831c28,
fs=0x11f831e68) at ../../gcc/config/alpha/linux-unwind.h:45
#1  0x020001887eac in uw_frame_state_for (context=0x11f831c28,
fs=0x11f831e68) at ../../gcc/unwind-dw2.c:978
#2  0x02000188a0bc in _Unwind_Backtrace (
trace=0x20001981700 , trace_argument=0x11f832320)
at ../../gcc/unwind.inc:296
#3  0x020001981804 in backtrace () from /lib/tls/libc.so.6.1
#4  0x02b833ec in gnu::gcj::runtime::StackTrace::fillInStackTrace (
this=0x20002839188, maxlen=Variable "maxlen" is not available.
)
at ../../../libjava/gnu/gcj/runtime/natStackTrace.cc:60
#5  0x02c5eaf4 in gnu.gcj.runtime.StackTrace.StackTrace(int) (
this=0x20002839188, n=128)
at ../../../libjava/gnu/gcj/runtime/StackTrace.java:67
#6  0x02bce9c4 in
java.lang.VMThrowable.fillInStackTrace(java.lang.Throwable) (t=Variable "t" is
not available.
) at ../../../libjava/java/lang/VMThrowable.java:80
#7  0x02bcbd20 in java.lang.Throwable.fillInStackTrace() (
this=0x200027f99a0) at ../../../libjava/java/lang/Throwable.java:502
#8  0x02bcb2d4 in java.lang.Throwable.Throwable(java.lang.String) (
this=0x200027f99a0, message=0x2000284d540)
at ../../../libjava/java/lang/Throwable.java:157
#9  0x02bb4de8 in java.lang.Exception.Exception(java.lang.String) (
this=Variable "this" is not available.
) at ../../../libjava/java/lang/Exception.java:77
#10 0x02bdb818 in java.io.IOException.IOException(java.lang.String) (
this=Variable "this" is not available.
) at ../../../libjava/java/io/IOException.java:71
#11 0x02b7e294 in gnu::gcj::Core::create (name=Variable "name" is not
available.
)
at ../../../libjava/gnu/gcj/natCore.cc:111
#12 0x02c9d0a8 in gnu.java.net.protocol.core.Connection.connect() (
this=Variable "this" is not available.
) at ../../../libjava/gnu/java/net/protocol/core/Connection.java:50
#13 0x02c9d348 in gnu.java.net.protocol.core.Connection.getHeaders() (
this=0x20002842f78)
at ../../../libjava/gnu/java/net/protocol/core/Connection.java:154
#14 0x02c9d6d8 in
gnu.java.net.protocol.core.Connection.getHeaderField(java.lang.String)
(this=0x20002842f78, name=0x20001ac9200)
at ../../../libjava/gnu/java/net/protocol/core/Connection.java:69
#15 0x02d35174 in
java.net.URLConnection.getHeaderFieldInt(java.lang.String, int) (this=Variable
"this" is not available.
) at ../../../libjava/java/net/URLConnection.java:343
#16 0x02d34f98 in java.net.URLConnection.getContentLength()
(this=Variable "this" is not available.
)
at ../../../libjava/java/net/URLConnection.java:220
#17 0x02d320a4 in
java.net.URLClassLoader$RemoteURLLoader.getResource(java.lang.String)
(this=0x20001b1d428, name=0x200028480c0)
at ../../../libjava/java/net/URLClassLoader.java:475
#18 0x02d33b74 in java.net.URLClassLoader.findClass(java.lang.String) (
this=0x20001b7fea0, className=0x2000284d5c0)
at ../../../libjava/java/net/URLClassLoader.java:921
#19 0x02c58d84 in
gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)
(this=0x20001b7fea0, name=0x2000284d5c0)
---Type  to continue, or q  to quit---
at ../../../libjava/gnu/gcj/runtime/BootClassLoader.java:52
#20 0x02b9bf44 in java::lang::VMClassLoader::loadClass (
name=0x2000284d5c0, resolve=0 '\0')
at ../../../libjava/java/lang/natVMClassLoader.cc:205
#21 0x02bb2e7c in java.lang.ClassLoader.loadClass(java.lang.String,
boolean) (this=0x20001b7ff80, name=0x2000284d5c0, resolve=false)
at ../../../libjava/java/lang/ClassLoader.java:304
#22 0x02bb2e5c in java.lang.ClassLoader.loadClass(java.la

[Bug libfortran/19595] [4.0 only] eor does not work

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-03 
19:45 ---
Patch committed to 4.0.1.  Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/21368] New: VRP does not know that &s.a != NULL

[kazu at cs dot umass dot edu]

Consider

struct s {
  int a;
} s;

int
foo (void)
{
  int *p = &s.a;

  if (p == 0)
return 123;

  /* Force VRP to run by having it insert at least one
 ASSERT_EXPR.  */
  *p = 456;

  return 0;
}

Note that with -fno-dominator-opts, VRP does not fold the "if" statement.

expr_computes_nonzero could use get_base_address.

-- 
   Summary: VRP does not know that &s.a != NULL
   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=21368

[Bug libfortran/20131] [4.0 only] gfortan - incorrectly reads beyond the end of line.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-03 
19:40 ---
Subject: Bug 20131

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-03 19:39:36

Modified files:
libgfortran: ChangeLog 
libgfortran/io : transfer.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: eor_handling_1.f90 eor_handling_2.f90 
   eor_handling_3.f90 eor_handling_4.f90 
   eor_handling_5.f90 noadv_size.f90 
   pad_no.f90 

Log message:
2005-05-03  Thomas Koenig <[EMAIL PROTECTED]>

Backport from mainline:
PR libfortran/17992
PR libfortran/19568
PR libfortran/19595
PR libfortran/20005
PR libfortran/20092
PR libfortran/20131
PR libfortran/20661
PR libfortran/20744
* io/transfer.c (top level): eor_condition: New static variable.
(read_sf): Remove unnecessary zeroing of buffer (there is enough
information in its length).
Return a string of length 0 (to be padded by caller) if EOR was
seen previously.
Remove erroneous special casing of EOR for standard input.
Set eor_condition for non-advancing I/O if an end of line was
detected.
Increment ioparm.size if necessary.
(formatted_transfer):  Skip the function if there is an EOR condition.
(data_transfer_init):  Initialize eor_condition to zero (false).
(next_record_r):  Clear sf_seen_eor if a \n has been seen already.
(finalize_transfer):  If there is an EOR condition, raise the error.

2005-05-03  Thomas Koenig  <[EMAIL PROTECTED]>

Backport from mainline:
* eor_handling_1.f90: New test case.
* eor_handling_2.f90: New test case.
* eor_handling_3.f90: New test case.
* eor_handling_4.f90: New test case.
* eor_handling_5.f90: New test case.
* noadv_size.f90: New test case.
* pad_no.f90: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.22&r2=1.163.2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.2&r2=1.32.2.3
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.156&r2=1.5084.2.157
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_3.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_handling_5.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/noadv_size.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pad_no.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.6.1



-- 


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