[Bug fortran/20835] error needed with EQUIVALENCE and TARGET

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 20835

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/20890] initializing two equivalenced variabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 20890

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/20901] different intrinsic types in equivalence not detected

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 20901

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/20902] can't equivalence derived types with default initialization

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 20902

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/20900] use-associated variable may not be equivalenced

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 20900

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/20899] pure function may not modify common variable through equivalence

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 20899

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/16404] should reject invalid code with -pedantic -std=f95 ? (x8)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
07:39 ---
Subject: Bug 16404

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 07:39:08

Modified files:
gcc/fortran: ChangeLog gfortran.h match.c resolve.c symbol.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg/g77: 980628-2.f 980628-3.f 980628-9.f 
   980628-10.f 
Added files:
gcc/testsuite/gfortran.dg: equiv_constraint_1.f90 
   equiv_constraint_2.f90 
   equiv_constraint_3.f90 
   equiv_constraint_4.f90 
   equiv_constraint_5.f90 
   equiv_constraint_6.f90 
   equiv_constraint_7.f90 
   equiv_constraint_8.f90 
   private_type_1.f90 private_type_2.f90 

Log message:
2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
* gfortran.h: Prototype for gfc_add_in_equivalence.
* match.c (gfc_match_equivalence): Make a structure component
an explicit,rather than a syntax, error in an equivalence
group.  Call gfc_add_in_equivalence to add the constraints
imposed in check_conflict.
* resolve.c (resolve_symbol): Add constraints: No public
structures with private-type components and no public
procedures with private-type dummy arguments.
(resolve_equivalence_derived): Add constraint that prevents
a structure equivalence member from having a default
initializer.
(sequence_type): New static function to determine whether an
object is default numeric, default character, non-default
or mixed sequence. Add corresponding enum typespec.
(resolve_equivalence): Add constraints to equivalence groups
or their members: No more than one initialized member and
that different types are not equivalenced for std=f95.  All
the simple constraints have been moved to check_conflict.
* symbol.c (check_conflict): Simple equivalence constraints
added, including those removed from resolve_symbol.
(gfc_add_in_equivalence): New function to interface calls
match_equivalence to check_conflict.

2005-10-01  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/16404
PR fortran/20835
PR fortran/20890
PR fortran/20899
PR fortran/20900
PR fortran/20901
PR fortran/20902
gfortran.dg/equiv_constraint_1.f90: New test.
gfortran.dg/equiv_constraint_2.f90: New test.
gfortran.dg/equiv_constraint_3.f90: New test.
gfortran.dg/equiv_constraint_4.f90: New test.
gfortran.dg/equiv_constraint_5.f90: New test.
gfortran.dg/equiv_constraint_6.f90: New test.
gfortran.dg/equiv_constraint_7.f90: New test.
gfortran.dg/equiv_constraint_8.f90: New test.
gfortran.dg/private_type_1.f90: New test.
gfortran.dg/private_type_2.f90: New test.
gfortran.dg/g77/980628-2.f, 980628-3.f, 980628-9.f,
980628-10.f: Assert std=gnu to permit mixing of
types in equivalence statements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.87&r2=1.88
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.c.diff?cvsroot=gcc&r1=1.45&r2=1.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.56&r2=1.57
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6119&r2=1.6120
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_6.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90.diff?cvsroot=gcc&r1=NON

[Bug fortran/24158] New: ICE in f951 with nested derived types

[pault at gcc dot gnu dot org]

[EMAIL PROTECTED] mytests]# cat snafu.f90
module snafu
  type   ::   a
type(b):: i
  end type a
  type   ::   b
type(c):: i
  end type b
  type   ::   c
type(a):: i
  end type c
  type (a)   :: foo
end module snafu

[EMAIL PROTECTED] mytests]# /gcc-clean/bin/gfortran -c snafu.f90
gfortran: Internal error: Segmentation fault (program f951)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: ICE in f951 with nested derived types
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libgcj/24154] Make requires too much memory building libjava

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2005-10-01 08:44 
---
Confirmed. I am also seeing this on my old PPC box which has just 192MB real
memory.  Since it has enough swap it does finish after a couple of hours of
swapping like mad.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-10-01 08:44:15
   date||


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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-10-01 
08:53 ---
I'm confused about the status of this bug.  I believe it is fixed on the 4.0
branch (originally for 4.0.2, but due to the release both, actually for 4.0.3).
 However, this bug is still marked as "New".  If the problem is fixed, please
close the PR.

Thanks,

-- Mark

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.3


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

[Bug objc/18255] [GNU runtime] Protocols are not initialized correctly

[tilo at pruetz dot net]

--- Additional Comments From tilo at pruetz dot net  2005-10-01 09:01 
---
Is there any hope that this bug will be fixed in a GCC release?

It really sucks to have to patch every new installed release.

What can I do to make the fix do it's way into a GCC release?

-- 


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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-10-01 
09:02 ---
> I'm confused about the status of this bug.  I believe it is fixed on the 4.0
> branch (originally for 4.0.2, but due to the release both, actually for 
> 4.0.3).
>  However, this bug is still marked as "New".  If the problem is fixed, please
> close the PR.

The fix is more of a workaround around the peculiarity of __gthread_active_p on
Solaris (duality Solaris/POSIX threads) than a fix, so I think the PR should be
kept open and the target milestone probably not set to 4.0.3.

-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-10-01 
09:17 ---
OK, I have unset the target milestone.

Thanks,

-- Mark

-- 
   What|Removed |Added

   Target Milestone|4.0.3   |---


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

[Bug fortran/24158] ICE in f951 with nested, recursive derived types

[pault at gcc dot gnu dot org]

--- Additional Comments From pault at gcc dot gnu dot org  2005-10-01 09:40 
---
Sorry, I meant to say that the recursiveness is not being resolved.

I have a fix in the pipeline.

-- 
   What|Removed |Added

Summary|ICE in f951 with nested |ICE in f951 with nested,
   |derived types   |recursive derived types


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

[Bug libstdc++/24159] New: Gcc 3.4.4 build fails

[biswadip at cal dot interrasystems dot com]

gcc version 3.4.4 build fails with the following type of errors :
ld: fatal: relocation error: R_SPARC_DISP32: file .libs/allocator.o: symbol
: offset 0x74cce9e1 is non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file .libs/codecvt.o: symbol
: offset 0x74ccea49 is non-aligned
Platform : Sun 5.8
Gcc used to build : 2.95.2
ld used : v2.16 ( Also failed with the default /usr/ccs/bin/ld with the same 
error)
Confure Options : ./configure --prefix=/software/gcc/v3.4.4/sparc-sun-solaris2.7
--enable-languages=c,c++ --enable-shared

-- 
   Summary: Gcc 3.4.4 build fails
   Product: gcc
   Version: 2.95.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: biswadip at cal dot interrasystems dot com
CC: gcc-bugs at gcc dot gnu dot org,sos at cal dot
interrasystems dot com
  GCC host triplet: Sun 5.8
GCC target triplet: gcc 3.4.4


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

[Bug libstdc++/24159] Gcc 3.4.4 build fails

[biswadip at cal dot interrasystems dot com]

--- Additional Comments From biswadip at cal dot interrasystems dot com  
2005-10-01 10:44 ---
Created an attachment (id=9854)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9854&action=view)
Outfile error in the file


-- 


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

[Bug middle-end/24151] [4.0/4.1 Regression] gcc.dg/asm-1.c (test for excess errors) fails

[paolo dot bonzini at lu dot unisi dot ch]

--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch  
2005-10-01 11:00 ---
Subject: Re:  [4.0/4.1 Regression] gcc.dg/asm-1.c (test
 for excess errors) fails

pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-30 
>19:36 ---
>Confirmed.  As noted before this checking really should be in the front-end 
>and it seems it also needs a 
>check for error_mark_node too.
>
I'm testing a patch which moves the warning to the front-ends (which is 
anyway unrelated to this PR) and checks for error_mark_node.

asm-1.c, by the way, is compiled (but of course not assembled) on every 
target.

Paolo



-- 


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

[Bug c++/22172] [3.4/4.0/4.1 Regression] Internal compiler error, seg fault.

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-10-01 
11:07 ---
This path is OK, without the spurious addition of the blank line.

-- 


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

[Bug c++/22621] [3.4/4.0/4.1 Regression] Member function overloading introduces syntax errors

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/24160] New: [4.1 Regression] ICE with -O3 -finline-limit=1024 -ftree-vectorize -ftracer

[drab at kepler dot fjfi dot cvut dot cz]

The example (attached below), when compiled by following gcc

---
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20050930/gcc-CVS-20050930/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/gcc-4.1 --sysconfdir=/etc
--libdir=/usr/local/opt/gcc-4.1/lib --libexecdir=/usr/local/opt/gcc-4.1/libexec
--sharedstatedir=/var --localstatedir=/var --program-suffix=-4.1
--with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib
--enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs
--enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage
--disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath
--enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization
--with-system-zlib --with-libbanshee --with-demangler-in-ld
--with-arch=athlon-xp --disable-libada --enable-languages=c,c++,f95,objc
Thread model: posix
gcc version 4.1.0 20050930 (experimental)
---

with

---
gcc -c -O3 -finline-limit=1024 -ftree-vectorize -ftracer -o minilzo.o minilzo.c
---

results in this:

---
native/minilzo.c: In function ‘__lzo_init2’:
native/minilzo.c:1278: error: unable to generate reloads for:
(insn:HI 394 392 396 29 (set (reg:V4SI 21 xmm0 [orig:93 vect_cst_.1512 ] [93])
(vec_duplicate:V4SI (plus:SI (reg/f:SI 6 bp)
(const_int -104 [0xff98] 757 {*vec_dupv4si} (nil)
(nil))
native/minilzo.c:1278: internal compiler error: in find_reloads, at 
reload.c:3730
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
---

This only fails on x86, on x86-64 it works. Also I did some checkings with some
older CVS's that I still have allready compiled and it seems that the regression
was introduced somewhere between CVS-20050723 (which works) and CVS-20050812
(which doesn't).

-- 
   Summary: [4.1 Regression] ICE with -O3 -finline-limit=1024 -
ftree-vectorize -ftracer
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
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=24160

[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O3 -finline-limit=1024 -ftree-vectorize -ftracer

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-10-01 12:57 ---
Created an attachment (id=9855)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9855&action=view)
This triggers the bug


-- 


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

[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O3 -finline-limit=1024 -ftree-vectorize -ftracer

[drab at kepler dot fjfi dot cvut dot cz]

--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz  
2005-10-01 13:05 ---
(In reply to comment #0)
...
> ---
> gcc -c -O3 -finline-limit=1024 -ftree-vectorize -ftracer -o minilzo.o 
> minilzo.c
> ---

It works when you either remove any of the options above, or lower the -O number
or lower the -finline-limit under 590 (but I suspect that would be specific to
the  test code).


-- 


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

[Bug target/23985] [3.4 regression] Memory aliasing information incorrect in inlined memcpy

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
13:31 ---
Subject: Bug 23985

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-10-01 13:31:39

Modified files:
gcc: ChangeLog 
gcc/config/arm : arm-protos.h arm.c arm.md 

Log message:
PR target/23985
Back-port 2004-08-19  Richard Henderson  <[EMAIL PROTECTED]>
* config/arm/arm.c (arm_gen_load_multiple): Use
adjust_automodify_address.  Take base memory and offset instead
of unchanging/struct/scalar bits.
(arm_gen_store_multiple): Likewise.
(arm_gen_movstrqi): Use adjust_automodify_address.
* config/arm/arm-protos.h: Update decls.
* config/arm/arm.md (load_multiple): Update arm_gen_load_multiple call.
(store_multiple): Similarly.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.918&r2=2.2326.2.919
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm-protos.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.61.4.1&r2=1.61.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.317.4.9&r2=1.317.4.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.md.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.154.4.3&r2=1.154.4.4



-- 


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

[Bug target/23985] [3.4 regression] Memory aliasing information incorrect in inlined memcpy

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-10-01 
13:33 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/23604] [4.1 Regression] wrong code due to VRP

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
13:57 ---
Subject: Bug 23604

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 13:57:30

Modified files:
gcc/testsuite  : ChangeLog 
gcc: ChangeLog tree-vrp.c 
Added files:
gcc/testsuite/gcc.c-torture/execute: pr23604.c 

Log message:
PR 23604
* tree-vrp.c (extract_range_from_assert): For !=
assertions, only build an anti-range if LIMIT is a
single-valued range.

testsuite/

PR 23604
* gcc.c-torture/execute/pr23604.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6120&r2=1.6121
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr23604.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10060&r2=2.10061
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.57&r2=2.58



-- 


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

[Bug c++/24161] New: Lookup of template member function finds global type.

[redi at gcc dot gnu dot org]

// A template class.
template< typename, typename > struct f {};

// A template function that calls a member template function.
template< typename T >
void call_f( T& t )
{
   t.template f< int >();
   // t.T::template f< int >();  // this line works
}


struct F {
template  void f() {}
};

int main()
{
F obj;
call_f(obj);
}

GCCs 3.4 - 4.1 error with:

phil2.cc: In function ‘void call_f(T&)’:
phil2.cc:8: error: wrong number of template arguments (1, should be 2)
phil2.cc:2: error: provided for ‘template struct f’


Shouldn't the lookup of the id-expression "template f" be done in the scope
of T according to 3.4.5/2, so shouldn't it be ignoring ::f ?

If you qualify the function call with "T::" it works as expected. 
If either ::f or ::call_f() is not a template, it works.

I expect the template-id "template f" to be dependent on T, so get looked
up at the point of instantiation, in the scope of F, finding F::f.  It seems
that either it isn't dependent (in which case it should not find F::F if you
comment out the declaration of ::f) or something means that lookup of a
template, within a template disregards 3.4.5/2.  Or it's a bug, but I'm not
convinced I haven't overlooked something.

-- 
   Summary: Lookup of template member function finds global type.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/24141] [4.1 regression] VRP ICE in compare_name_with_value, at tree-vrp.c:2965

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-10-01 
14:00 ---
Subject: Bug 24141

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-10-01 14:00:09

Modified files:
gcc: ChangeLog tree-vrp.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: pr24141.c 

Log message:
PR 24141
* tree-vrp.c (vrp_meet): Clear VR0->EQUIV when building a
non-null range as a last resort.

testsuite/

PR 24141
* gcc.c-torture/execute/pr24141.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10061&r2=2.10062
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.58&r2=2.59
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6121&r2=1.6122
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr24141.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/24139] Forward declaration of class in template class

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2005-10-01 14:18 
---
Matthew has a point about "Hidden" being confusing in the diagnostic, as
Hidden is not a template.

I notice if you define the Hidden constructor inline in the Hide::Hidden
class body then it works (with Comeau as well, if you move the Hide ctor
after the Hide::Hidden definition to avoid the first error.)

This is because Hide::Hidden is not a template, so the definition of the
Hidden ctor should not have "template<>" before it - it's not a template
specialisation, it the definition of a non-template function.

However, GCC wrongly rejects the code if you remove the "template<>" (which
might already be filed as a bug, I can't remember):

pr24139.cc:27: error: explicit specialization of
‘Hide::Hidden::Hidden()’ must be introduced by ‘template <>’
pr24139.cc:27: error: template-id ‘Hidden<>’ for
‘Hide::Hidden::Hidden()’ does not match any template declaration
pr24139.cc:27: error: invalid function declaration

The first line is wrong, it is not an explicit specialisation.



-- 
   What|Removed |Added

 CC||redi at gcc dot gnu dot org


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

[Bug tree-optimization/23604] [4.1 Regression] wrong code due to VRP

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-10-01 
14:19 ---

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00020.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]

[dnovillo at gcc dot gnu dot org]

-- 
Bug 23603 depends on bug 23604, which changed state.

Bug 23604 Summary: [4.1 Regression] wrong code due to VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604

   What|Old Value   |New Value

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

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

[Bug tree-optimization/23968] [meta-bug] VRP bug reports

[dnovillo at gcc dot gnu dot org]

-- 
Bug 23968 depends on bug 23604, which changed state.

Bug 23604 Summary: [4.1 Regression] wrong code due to VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/24141] [4.1 regression] VRP ICE in compare_name_with_value, at tree-vrp.c:2965

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-10-01 
14:20 ---

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00021.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/23968] [meta-bug] VRP bug reports

[dnovillo at gcc dot gnu dot org]

-- 
Bug 23968 depends on bug 24141, which changed state.

Bug 24141 Summary: [4.1 regression] VRP ICE in compare_name_with_value, at 
tree-vrp.c:2965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24141

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O3 -finline-limit=1024 -ftree-vectorize -ftracer

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-10-01 14:36 ---
// Confirmed, reduced testcase (compile with -O1 -ftree-vectorize -msse):

void foo (char **p)
{
  int i;
  char q [1024], *r;
  r = q + unsigned long) q + 3) / 4) * 4) - (unsigned long) q;
  for (i = 0; i < 10; i++)
p [i] = r;
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-10-01 14:36:48
   date||


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

[Bug c++/24139] Forward declaration of class in template class

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2005-10-01 14:41 
---
14.7.3/5

"Definitions of members of an explicitly specialized class are defined in the
same manner as member of normal classes, and not using the explicit
specialization syntax."

-- 


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

[Bug c++/24139] Forward declaration of class in template class

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2005-10-01 14:52 
---
This is a revised version, which should compile but doesn't:

#include 
using namespace std;

template
class Hide {
 public:
   Hide();

  class Hidden;

private:
  Hidden *a;
};

template<>
class Hide::Hidden
{
 public:
  Hidden();
};

template<>
Hide::Hide() {
  a=new Hidden();
}

// N.B.  no "template<>"
Hide::Hidden::Hidden() {
  cout << "Hello from int->Hidden" << endl;
}

int main(int argc,char *argv[])
{
  Hide b;
}


pr24139.2.cc:28: error: explicit specialization of
‘Hide::Hidden::Hidden()’ must be introduced by ‘template <>’
pr24139.2.cc:28: error: template-id ‘Hidden<>’ for
‘Hide::Hidden::Hidden()’ does not match any template declaration
pr24139.2.cc:28: error: invalid function declaration




-- 


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

[Bug c++/23885] incorrect template two-stage name-lookup

[redi at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||redi at gcc dot gnu dot org


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

[Bug tree-optimization/24142] [4.1 regression] VRP miscompiles unzip inflate.c

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-10-01 15:24 ---
(In reply to comment #3)
> I'm not so sure that this is a dup.  Bug 24141 is a wrong-code problem, 
> and this is an ICE.  Just the fact that the same test case triggers both 
> bugs doesn't mean they are the same problem. 
>  
>  

You are right, this is not a dup. original testcase still fails even after bug
24141 fixed:

void abort (void);

int f (int a, int b)
{
  if (a == 1)
a = 0;
  if (b == 0)
a = 1;
  if (a != 0)
return 0;
  return 1;
}

int main (void)
{
  if (f (1, 1) != 1)
abort ();
  return 0;
}


-- 
   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org
 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug tree-optimization/23968] [meta-bug] VRP bug reports

[belyshev at depni dot sinp dot msu dot ru]

-- 
Bug 23968 depends on bug 24142, which changed state.

Bug 24142 Summary: [4.1 regression] VRP miscompiles unzip inflate.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24142

   What|Old Value   |New Value

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |

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

[Bug tree-optimization/24142] [4.1 regression] VRP miscompiles unzip inflate.c

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-10-01 15:26 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-10-01 15:26:51
   date||


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

[Bug tree-optimization/24142] [4.1 regression] VRP miscompiles unzip inflate.c

[dnovillo at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O3 -finline-limit=1024 -ftree-vectorize -ftracer

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet||i686-pc-linux-gnu
   Keywords||ssemmx
   Target Milestone|--- |4.1.0


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

[Bug java/24162] New: internal compiler error, make_class_data

[bflat1 at gmx dot net]

I got the following error output when trying to compile a jar file from the 
limewire project (http://www.limewire.org/): 
 
 
 gcj -v -save-temps core.jar  
Using built-in specs. 
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../libgcj.spec 
rename spec lib to liborig 
Target: i486-linux-gnu 
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr 
--disable-werror --enable-checking=release i486-linux-gnu 
Thread model: posix 
gcc version 4.0.2 (Debian 4.0.1-9) 
 /usr/lib/gcc/i486-linux-gnu/4.0.2/jc1 core.jar -fhash-synchronization 
-fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions 
-fno-omit-frame-pointer -fkeep-inline-functions -quiet -dumpbase core.jar 
-mtune=i486 -auxbase core -g1 -version -o core.s 
GNU Java version 4.0.2 (Debian 4.0.1-9) (i486-linux-gnu) 
compiled by GNU C version 4.0.2 (Debian 4.0.1-9). 
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113113 
Class path starts here: 
./ 
/usr/java/j2sdk1.4.1_03/jre/lib/rt.jar/ (zip) 
/usr/share/java/libgcj-4.0.2.jar/ (system) (zip) 
java/lang/String.java:18: internal compiler error: in make_class_data, at 
java/class.c:1760

-- 
   Summary: internal compiler error, make_class_data
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bflat1 at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC target triplet:  i486-linux-gnu


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

[Bug fortran/24158] ICE in f951 with nested, recursive derived types

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:38 ---
Confirmed.  This is invalid code unless they used POINTER correct?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2005-10-01 15:38:12
   date||


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

[Bug c++/24157] g++ allows variable to be initialized by value of variable being initialized

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:40 ---
for:
int i = i;

The code is valid but undefined.


You have to use -Winit-self.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/5582] warn about using the extension "int x=x;"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:40 ---
*** Bug 24157 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||gahs at phys dot ksu dot edu


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

[Bug target/24159] Gcc 3.4.4 build fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:43 ---
What as version are you using?

-- 
   What|Removed |Added

  Component|libstdc++   |target
   GCC host triplet|Sun 5.8 |
 GCC target triplet|gcc 3.4.4   |sparc-sun-solaris2.8
Version|2.95.2  |3.4.4


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

[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken

[hubicka at gcc dot gnu dot org]

--- Additional Comments From hubicka at gcc dot gnu dot org  2005-10-01 
15:45 ---
Well, if the exception is never raised, the difference in EH code generation is 
probably not an issue.
Reverting the patch is definitly possible (there is nothing dependent on it and 
except for one or two PRs exposing problems in libcall mechanizm it only results
in better code.  However this is almost definitly previously latent bug (we 
just disable RTL level optimizatoin), I would like to have some understanding 
to what is going wrong.

Honza

-- 


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

[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:49 ---
Confirmed, 3.3 accepted the code.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0 4.1.0 3.4.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-10-01 15:49:01
   date||
Summary|Lookup of template member   |[3.4/4.0/4.1 Regression]
   |function finds global type. |Lookup of template member
   ||function finds global type.
   Target Milestone|--- |4.0.3


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

[Bug libfortran/24112] Reopening file with STATUS='OLD' doesn't work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:56 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20835] error needed with EQUIVALENCE and TARGET

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:56 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20890] initializing two equivalenced variabled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:56 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20405] [meta-bug] equivalenced variable problems

[pinskia at gcc dot gnu dot org]

-- 
Bug 20405 depends on bug 20890, which changed state.

Bug 20890 Summary: initializing two equivalenced variabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20890

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug fortran/20405] [meta-bug] equivalenced variable problems

[pinskia at gcc dot gnu dot org]

-- 
Bug 20405 depends on bug 20901, which changed state.

Bug 20901 Summary: different intrinsic types in equivalence not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20901

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug fortran/20901] different intrinsic types in equivalence not detected

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:57 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20902] can't equivalence derived types with default initialization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:57 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20900] use-associated variable may not be equivalenced

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:57 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20405] [meta-bug] equivalenced variable problems

[pinskia at gcc dot gnu dot org]

-- 
Bug 20405 depends on bug 20900, which changed state.

Bug 20900 Summary: use-associated variable may not be equivalenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20900

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug fortran/20899] pure function may not modify common variable through equivalence

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:57 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug fortran/20405] [meta-bug] equivalenced variable problems

[pinskia at gcc dot gnu dot org]

-- 
Bug 20405 depends on bug 20899, which changed state.

Bug 20899 Summary: pure function may not modify common variable through 
equivalence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20899

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug fortran/16404] should reject invalid code with -pedantic -std=f95 ? (x8)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
15:58 ---
Fixed now.

-- 
   What|Removed |Added

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


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

[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-10-01 16:00 
---
Either GCC is installed or not.  If it's installed, you should not need any -B
options.

-- 


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

[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-10-01 16:04 
---
Ok, no need to revert it right now. I'm trying to reduce it to something
standalone that doesn't call the Ada runtime.

-- 


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

[Bug c++/24163] New: Base class scope examined during unqualified name lookup

[redi at gcc dot gnu dot org]

(I first posted this code to PR5660 but it's apparently a separate issue)

   template 
 struct A
 {
 typedef T Type;
 void f(Type) {}
 };

   template 
 struct B : A
 {
 typedef typename A::Type Type;
 void ff(Type t) { f(t); } // XXX
 };

   template struct B;

This should fail to compile, according to 14.6.2/3, but 3.4 - 4.1 (and probably
earlier) accept it.

If A::f and the call to it are changed to take no arguments (so that f is not a
dependent name) then it fails, so it is apparently only at instantiation that
the base class scope is examined.

-- 
   Summary: Base class scope examined during unqualified name lookup
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/24163] Base class scope examined during unqualified name lookup

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
16:28 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||2.95.3 3.2.3 3.3.1 3.3.3
   ||3.4.3 4.0.0 4.1.0 3.0.4
   Last reconfirmed|-00-00 00:00:00 |2005-10-01 16:28:10
   date||


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

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-10-01 16:46 ---
You also have access to a GNU system, GNU/Linux.  It is easily testable there. 
Could you revert the fix?  It is better that fails loudly than having a
arbitrary limit.

I'll see about submiting a proper patch.

-- 


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

[Bug c++/24163] Base class scope examined during unqualified name lookup in template

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2005-10-01 16:48 
---
Adding "... in template" to end of title.


-- 
   What|Removed |Added

Summary|Base class scope examined   |Base class scope examined
   |during unqualified name |during unqualified name
   |lookup  |lookup in template


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

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-10-01 16:58 ---
Could someone go over these bugs and commit the pending patches?


-- 


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

[Bug fortran/24158] ICE in f951 with nested, recursive derived types

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-10-01 
16:59 ---
Subject: Re:  ICE in f951 with nested, recursive derived
 types

pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
>15:38 ---
>Confirmed.  This is invalid code unless they used POINTER correct?
>
>  
>
Andrew,

I would say so, yes, but it is possibly invalid even with a pointer -see 
the fortran list.

With the patch that I have readied for PR24092, gfortran does fine with 
the pointer case; Lahey, Intel and Digital all barf on it.

It seems that recursion detection is done in the commercial compilers by 
demanding that derived type components are already specified.  I do not 
see this anywhere in the standard and so have built a little recusion 
detector for resolve.c.

I will endeavour to clarify this point before heading off on a trip 
tomorrow night.

Best regards

Paul



-- 


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

[Bug tree-optimization/24141] [4.1 regression] VRP ICE in compare_name_with_value, at tree-vrp.c:2965

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-10-01 
17:00 ---
Diego, you only fixed the ICE, not the wrong-code.  Please continue with 24142
which tracks the wrong-code issue.

-- 


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

[Bug c++/24164] New: Explicit instantiation of template has no effect.

[gcc-bugzilla at gcc dot gnu dot org]

Here are three files that illustrate the problem.  
Header file "t.hpp":
namespace arrpp {

template 
class A {
public:
A();
};
}

File implementing class A, called t.cc:

#include "t.hpp"
template class arrpp::A;// instatiate class
template  arrpp::A:: A(){} // define ctor

File containing main, called xt.cc:
#include "t.hpp"
int main(int argc, char **argv) { arrpp::A x; }

Produce t.o and xt.o:
gcc -c t.cc xt.cc

Examine symbols in t.o:
nm t.o
(Produces no output, indicating that no symbols are defined.)

Try to link object files:
 gcc -o xt xt.o t.o -lstdc++
 xt.o: In function `main':
 xt.cc:(.text+0x24): undefined reference to `arrpp::A::A()'
 collect2: ld returned 1 exit status

On a machine with g++-3.3, this code works fine (links and runs, producing no
output).

Environment:
System: Linux dogwood 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls 
--without-included-gettext --enable-threads=posix --program-suffix=-4.0 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr 
--disable-werror --enable-checking=release i486-linux-gnu

How-To-Repeat:
See above.  Here is the preprocessor output for t.cc:

# 1 "t.cc"
# 1 ""
# 1 ""
# 1 "t.cc"
# 1 "t.hpp" 1
namespace arrpp {

template 
class A {
public:
 A();
};
}
# 2 "t.cc" 2

template class arrpp::A;

template 
arrpp::A::
A(){}

Here is the preprocessor output for xt.cc:

# 1 "xt.cc"
# 1 ""
# 1 ""
# 1 "xt.cc"
# 1 "t.hpp" 1
namespace arrpp {

template 
class A {
public:
 A();
};
}
# 2 "xt.cc" 2

int main(int argc, char **argv) {
arrpp::A x;
}
--- Additional Comments From rogers at anthro dot utah dot edu  2005-10-01 
17:04 ---
Fix:
Here is a patch for t.cc that provides a work-around.  It instantiates
the class by declaring a variable:

--- t.cc2005-10-01 10:53:33.038810604 -0600
+++ t2.cc   2005-10-01 10:53:47.335552612 -0600
@@ -1,6 +1,6 @@
 #include "t.hpp"
 
-template class arrpp::A;
+arrpp::A foo;
 
 template 
 arrpp::A::

-- 
   Summary: Explicit instantiation of template has no effect.
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogers at anthro dot utah dot edu
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug c++/24164] Explicit instantiation of template has no effect.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
17:07 ---
This is already fixed in 4.0.2 and above.

This is a dup of bug 22263.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/22263] [4.0/4.1 Regression] explicit instantiation fails to emit symbols defined later

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
17:07 ---
*** Bug 24164 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||rogers at anthro dot utah
   ||dot edu


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

[Bug target/24159] Gcc 3.4.4 build fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
17:13 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/10057] [Sparc/Solaris 2.6] relocation error when creating libstdc++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
17:13 ---
*** Bug 24159 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||biswadip at cal dot
   ||interrasystems dot com


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

[Bug target/11594] testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.5   |---


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

[Bug middle-end/23669] fold does convert (-a)/10 into a/-10.

[mrnobo1024 at yahoo dot com]

--- Additional Comments From mrnobo1024 at yahoo dot com  2005-10-01 17:25 
---
Those expressions are only the same for floating point types.

f(-2147483648)  == -214748364
f1(-2147483648) == 214748364

-- 


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

[Bug middle-end/23669] fold does convert (-a)/10 into a/-10 with -fno-wrapv

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
17:34 ---
(In reply to comment #2)
> Those expressions are only the same for floating point types.

But -a for INT_MIN is undefined for signed type since it is an overflow.  So 
the conversion is only valid 
for -fno-wrapv which is default for C, C++, Ada, and fortran.

-- 
   What|Removed |Added

Summary|fold does convert (-a)/10   |fold does convert (-a)/10
   |into a/-10. |into a/-10 with -fno-wrapv


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

[Bug java/24162] internal compiler error, make_class_data

[mark at klomp dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2005-10-01 17:40 
---
Subject: Re:  New: internal compiler error, make_class_data

On Sat, 2005-10-01 at 15:33 +, bflat1 at gmx dot net wrote:
> Class path starts here: 
> ./ 
> /usr/java/j2sdk1.4.1_03/jre/lib/rt.jar/ (zip) 
> /usr/share/java/libgcj-4.0.2.jar/ (system) (zip) 
> java/lang/String.java:18: internal compiler error: in make_class_data, at 
> java/class.c:1760

gcj shouldn't crash of course, but are you sure that rt.jar on your
Class path is correct? Kaffe comes with an rt.jar which contains kaffe's
bootstrap classes, some other runtimes also ship with something called
rt.jar. But gcj doesn't. Mixing bootstrap classes from different
compilers/runtimes doesn't work.



-- 


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

[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-10-01 17:41 
---
Workaround patch here:
http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html

Rest of discussion here:
http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html

Seems to be a gnatbind bug present on 4.0 and 4.1.

-- 
   What|Removed |Added

  Component|target  |ada
  GCC build triplet|alpha-dec-osf5.1b   |
   GCC host triplet|alpha-dec-osf5.1b   |
 GCC target triplet|alpha*  |
Summary|[4.0/4.1 Regression] Cannot |[4.0/4.1 Regression] Ada:
   |build gnattools on Tru64|cannot build gnattools on
   |UNIX V5.1B  |Tru64 UNIX V5.1B


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

[Bug inline-asm/24165] New: asm volatile instructions incorrectly scheduled.?

[bjoern dot m dot haase at web dot de]

This bug report refers to the discussion on 
 
[bug #14616] definition of sei() in interrupts.h is faulty 
 
 
and the according discussion thread on [avr-libc-dev]  
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev/ 
 
 
The issue is the question if for the following test case gcc is allowed to 
schedule or not allowed to schedule an asm volatile instruction (the text of 
this comment continues after the test case). For clarity the actual asm 
instructions have been replaced by comments illustrating the meaning: 
 
 
/* Start of test case */ 
 
typedef unsigned char  uint8_t; 
typedef unsigned short int uint16_t; 
 
class class_with_volatile_data_structures 
{ 
  public: 
 
  void __attribute__ ((always_inline)) 
  wait_for_event (uint16_t event) 
   { 
 while (getval_protected () != event) 
   ; 
   }; 
 
  private: 
 
  uint16_t 
  getval_protected (void) 
  { 
uint16_t result; 
 
asm volatile ("/* disable irq in cpu status */" : : ); 
result = class_local_data; 
asm volatile ("/* enable irq */" : : ); 
 
return result; 
  } 
 
  volatile uint16_t class_local_data; 
}; 
 
class_with_volatile_data_structures object; 
 
void 
wait_for_42 (void) 
{ 
  object.wait_for_event (42); 
} 
 
/* End of test case */ 
 
 
Compiler output reads for (buggy ?) avr-g++ (GCC) 4.0.0 
 
 
_Z11wait_for_42v: 
.L2: 
/* #APP */ 
/* disable irq in cpu status */ 
/* enable irq */ 
/* #NOAPP */ 
lds r24,object 
lds r25,(object)+1 
sbiw r24,42 
brne .L2 
ret 
 
and for avr-g++ (GCC) 4.0.1 20050624 (prerelease) 
 
_Z11wait_for_42v: 
.L2: 
/* #APP */ 
/* disable irq in cpu status */ 
/* #NOAPP */ 
lds r24,object 
lds r25,(object)+1 
/* #APP */ 
/* enable irq */ 
/* #NOAPP */ 
sbiw r24,42 
brne .L2 
ret 
 
. So for the more recent version the acess to the variable is protected and for 
the original first 4.0.0 release not. If  
 
asm volatile ("/* disable irq in cpu status */" : : : "memory"); 
 
is used, the variable access was protected for both compiler versions. 
 
The important question for the avr-libc header files is now:  
 
According the specification, what is guaranteed by gcc concerning volatile asm 
statements? According to the spec 
 
>  The `volatile' keyword indicates that the instruction has important 
> side-effects.  GCC will not delete a volatile `asm' if it is reachable. 
> (The instruction can still be deleted if GCC can prove that 
> control-flow will never reach the location of the instruction.)  In 
> addition, GCC will not reschedule instructions across a volatile `asm' 
> instruction. 
 
, I'd like to assume that the "memory" clobbers should not be required.? 
 
Bjoern

-- 
   Summary: asm volatile instructions incorrectly scheduled.?
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: present on i586-linux, x86_64-linux and i586 cygwin
  GCC host triplet: present on i586-linux, x86_64-linux and i586 cygwin
GCC target triplet: avr-*-*


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

[Bug java/24162] internal compiler error, make_class_data

[bflat1 at gmx dot net]

--- Additional Comments From bflat1 at gmx dot net  2005-10-01 18:02 ---
Thanks for the hint, removing rt.jar from the CLASSPATH variable fixed this 
problem which was then superseded by the following: 
 
 gcj -v -save-temps core.jar  
Using built-in specs. 
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../libgcj.spec 
rename spec lib to liborig 
Target: i486-linux-gnu 
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr 
--disable-werror --enable-checking=release i486-linux-gnu 
Thread model: posix 
gcc version 4.0.2 (Debian 4.0.1-9) 
 /usr/lib/gcc/i486-linux-gnu/4.0.2/jc1 core.jar -fhash-synchronization 
-fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions 
-fno-omit-frame-pointer -fkeep-inline-functions -quiet -dumpbase core.jar 
-mtune=i486 -auxbase core -g1 -version -o core.s 
GNU Java version 4.0.2 (Debian 4.0.1-9) (i486-linux-gnu) 
compiled by GNU C version 4.0.2 (Debian 4.0.1-9). 
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113113 
Class path starts here: 
/usr/share/java/commons-logging.jar/ (zip) 
../../lib/jars/clink.jar/ (zip) 
/usr/share/java/libgcj-4.0.2.jar/ (system) (zip) 
 
jc1: out of memory allocating 1342179073 bytes after a total of 492188 bytes 
 

-- 
   What|Removed |Added

 GCC target triplet| i486-linux-gnu |i486-linux-gnu


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

[Bug inline-asm/24165] asm volatile instructions incorrectly scheduled.?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
18:06 ---
Huh, so you are saying that 4.0.1 is fixed?

I don't understand why this is being reported as 4.0.1 has been released for a 
while now and 4.0.2 was 
just released too.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-09-27 07:14:13 |2005-10-01 18:45:54
   date||


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

[Bug inline-asm/24165] asm volatile instructions incorrectly scheduled.?

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-10-01 18:46 ---
The question merely is to find out if this is a bug / a bug of the 
documentation or no bug at all.  
 
After the fix for PR22000 the actual issue I had stepped over originally is 
indeed fixed: The protection of volatile *variables* now indeed works. The 
question that is still open, however, is:  Is gcc generally allowed to schedule 
statements across asm volatile statements?  E.g. look at an hypothetical 
example where someone would, e.g. like to disable irqs for speed reasons. 
 
asm volatile ("/* disable irq */" : : );// 1 
for (i=0; i < 1000; i++)// 2 
  { 
a [i] *= 3; 
  } 
asm volatile ("/* enable irq */" : : ); // 3 
 
After reading the specs "In addition, GCC will not reschedule instructions 
across a volatile `asm' instruction.", I still think that we either  
 
1) still have a bug or 
2) have a documentation that "caused at least some people to understand it 
differently from than it was meant to be understood" (saying this in order to 
avoid the terminus documentation bug). 
 
In case that scheduling is meant to be allowed if no volatile variable access 
is concerned, we probably would need to change the present implementation of 
irq disabling in the avr-libc's header files. 
 
Bjoern 

-- 


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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-10-01 18:50 
---

Hey dudes. 

Mark, the original problem report, the fails, is fixed on mainline and on the
gcc-4_0-branch. It looks like the fix for this, after all our effort, did not
make it into 4.0.2. Whoops: mistakes happen. I didn't consider this stop-ship
then and certainly don't now, and think that the notes Eric made (use -pthreads
if using __mt_allocator) are an acceptable workaround.

However, there is a bigger issue involved, which is still in progress. Actually,
I'd like to broaden this out a bit since it looks like we are thinking of
solving a related issue on linux as well. (See RH bugzilla, link below)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165728

Therefore, I'm suggesting I close this, and open a more general enhancement bug.

That might clarify the situation for everybody.

-benjamin

-- 


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

[Bug libstdc++/24071] solaris vs. __gthread_active_p

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
19:41 ---
(In reply to comment #6)
> However, there is a bigger issue involved, which is still in progress. 
> Actually,
> I'd like to broaden this out a bit since it looks like we are thinking of
> solving a related issue on linux as well. (See RH bugzilla, link below)
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165728

And this has been a bug for a long time in the FSF GCC, PR 4372.
I don't think there is an easy solution other than fixing glibc, just ot be 
thread by default and not have 
libpthread.

-- 


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

[Bug classpath/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-10-01 
19:47 ---
This was fixed a while ago and the fix has since been
imported into the libgcj build.


-- 
   What|Removed |Added

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


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

[Bug tree-optimization/17884] asm 'volatile' is not honored as documented

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
19:48 ---
*** Bug 24165 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||bjoern dot m dot haase at
   ||web dot de


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

[Bug inline-asm/24165] asm volatile instructions incorrectly scheduled.?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-10-01 
19:48 ---
The documention was changed for 4.0.0, see PR 17884.
And see http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01120.html


So this is a dup of bug 17884.

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

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug debug/7081] DWARF enhancements for C++

[dberlin at gcc dot gnu dot org]

--- Comment #9 from dberlin at gcc dot gnu dot org  2005-10-02 01:15 ---
I won't get back to this for a while


-- 

dberlin at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dberlin at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  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=7081

[Bug tree-optimization/22254] We never call may_alias_p for PARM_DECL's

[dberlin at dberlin dot org]

--- Comment #4 from dberlin at gcc dot gnu dot org  2005-10-02 02:05 ---
Subject: Bug 22254

I actually came across a case recently where we do call it for 
PARM_DECL's.
I'll try to find it again


-- 


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

[Bug tree-optimization/24141] [4.1 regression] VRP ICE in compare_name_with_value, at tree-vrp.c:2965

[dnovillo at redhat dot com]

--- Comment #14 from dnovillo at redhat dot com  2005-10-02 02:11 ---
Subject: Re:  [4.1 regression] VRP ICE in compare_name_with_value, at
tree-vrp.c:2965

On October 1, 2005 13:00, rguenth at gcc dot gnu dot org wrote:

> Diego, you only fixed the ICE, not the wrong-code.  Please continue
> with 24142 which tracks the wrong-code issue.

OK, thanks for testing.


-- 


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

[Bug bootstrap/24094] AIX 51 configure fails with getopt.h not found

[dje at gcc dot gnu dot org]

--- Comment #5 from dje at gcc dot gnu dot org  2005-10-02 04:38 ---
libjava and fastjar currently are not a supported configuration on AIX.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04

[dje at gcc dot gnu dot org]

--- Comment #4 from dje at gcc dot gnu dot org  2005-10-02 04:45 ---
Also, why are you adding "--with-ld=/usr/ccs/bin/ld" to the configure command? 
There should be only one "ld" on the system and the GCC configuration process
should find it automatically?  Do you have GNU Binutils installed?  It also is
possible that the gcc-4.0.0-20040919 snapshot cannot bootstrap GCC.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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