[Bug c/25897] GCC rejects the following strictly conforming code with -ansi -pedantic errors
--- Comment #2 from neil at gcc dot gnu dot org 2006-01-21 08:02 --- Discussing with pinskia, I believe qualifying the array type is intended to be viewed as qualifying the element type, not the array, so the example is invalid. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25897
[Bug target/25898] New: [4.2 Regression] All Ada tests fail
Every Ada tests fail on the mainline with the following error: /home/pinskia/src/checkin/trunk/objdir/gcc/testsuite/ada/acats/tests/a/a22006b.ada:0: error: bad value (generic) for -mtune= switch -- Summary: [4.2 Regression] All Ada tests fail Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug target/25898] [4.2 Regression] All Ada tests fail
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 08:06 --- Caused by: 2006-01-19 Jan Hubicka <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> Evandro Menezes <[EMAIL PROTECTED]> * invoke.texi (generic): Document (i686) Update. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 08:07 --- Oh, I don't understand why -mcpu and -mtune don't take the same arguments. Maybe Ada is assuming they do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #27 from dick_guertin at yahoo dot com 2006-01-21 08:17 ---
Referring to Comment #26, these static objects are NOT all of one type, but
they share a common typedef struct, something like a union of different types
that share the same space. Each type is a constructor allowing initialization
to occur different ways. NKW and 'struct sckw" are two examples, and both
appear in Comment #25.
What I finally did was add a pointer to each object that points to another
object, usually of its own type. But the pointer can by cast so that a
different type can be referenced. Thus the pointer in NKW can be cast as an
NKW pointer even though it points to a 'struct sckw' object, and vice-versa.
To make this work, I had to reverse the declaration order so that the last is
declared first, and the first is declared last. So the new 'first' (old
'last') has a zero pointer. Those which follow point back to the one before
it. This does two things: it guarantees every object is referenced so it
isn't eliminated, and they can now be placed anywhere in memory. Instead of
ticking through them with 'kwp += 1;', I navigate thru them with 'kwp =
kwp->next;'. The chain stops when kwp goes to zero (first declared, last
examined).
In cases where an array of like-kind objects was initialized, I simply point
down the list, such as:
static NKW item[] =
{ SCKW_TOKEN("IF",xif,NKWFSET+NKWFCRTN, &item[1]),
SCKW_TOKEN("SHOW",show,NKWFSET+NKWFCRTN, &item[2]),
SCKW_TOKEN("SET",set,NKWFSET+NKWFCRTN, (NKW*)0)
};
I'm documenting this just in case it can be useful to someone else with a
similar problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-01-21 08:49 --- (In reply to comment #8) > I am going to declare this is GMP bug as I can reproduce it on two out of > three > of my machines. The one with the newest GMP, it works. These three machines > are all different targets, powerpc, x86 and x86-64. Unfortunately I can reproduce it with GMP 4.1.4 now :( This is on an Athlon64 with Suse 10.0, using the GMP 4.1.4 coming with the distribution. What do we do? BTW, the GMP people have a big notice on their web page that recent gcc versions often miscompile GMP. That could of course be a problem of the GMP code as well, but maybe the GMP testsuite should be used regularly to test GCC builds. This is especially important since gfortran relies on GMP and MPFR working properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug fortran/25538] internal compiler error: in build_function_decl, at fortran/trans-decl.c:1130
--- Comment #4 from pault at gcc dot gnu dot org 2006-01-21 09:09 --- Subject: Bug 25538 Author: pault Date: Sat Jan 21 09:08:54 2006 New Revision: 110063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110063 Log: 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * decl.c (get_proc_name): If there is an existing symbol in the encompassing namespace, call errors if it is a procedure of the same name or the kind field is set, indicating a type declaration. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * decl.c (add_global_entry): New function to check for existing global symbol with this name and to create new one if none exists. (gfc_match_entry): Call add_global_entry before matching argument lists for subroutine and function entries. * gfortran.h: Prototype for existing function, global_used. * resolve.c (resolve_global_procedure): New function to check global symbols for procedures. (resolve_call, resolve_function): Calls to this new function for non-contained and non-module procedures. * match.c (match_common): Add check for existing global symbol, creat one if none exists and emit error if there is a clash. * parse.c (global_used): Remove static and use the gsymbol name rather than the new_block name, so that the function can be called from resolve.c. (parse_block_data, parse_module, add_global_procedure): Improve checks for existing gsymbols. Emit error if already defined or if references were to another type. Set defined flag. PR fortran/PR24276 * trans-expr.c (gfc_conv_aliased_arg): New function called by gfc_conv_function_call that coverts an expression for an aliased component reference to a derived type array into a temporary array of the same type as the component. The temporary is passed as an actual argument for the procedure call and is copied back to the derived type after the call. (is_aliased_array): New function that detects an array reference that is followed by a component reference. (gfc_conv_function_call): Detect an aliased actual argument with is_aliased_array and convert it to a temporary and back again using gfc_conv_aliased_arg. 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * gfortran.dg/internal_references_1.f90: New test. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * gfortran.dg/global_references_1.f90: New test. * gfortran.dg/g77/19990905-1.f: Restore the error that there is a clash between the common block name and the name of a subroutine reference. PR fortran/PR24276 * gfortran.dg/aliasing_dummy_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/global_references_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_references_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/g77/19990905-1.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25538
[Bug c++/25625] [4.0/4.1/4.2 Regression] Fails to compile C++ code when -frepo is specified.
--- Comment #10 from pault at gcc dot gnu dot org 2006-01-21 09:09 --- Subject: Bug 25625 Author: pault Date: Sat Jan 21 09:08:54 2006 New Revision: 110063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110063 Log: 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * decl.c (get_proc_name): If there is an existing symbol in the encompassing namespace, call errors if it is a procedure of the same name or the kind field is set, indicating a type declaration. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * decl.c (add_global_entry): New function to check for existing global symbol with this name and to create new one if none exists. (gfc_match_entry): Call add_global_entry before matching argument lists for subroutine and function entries. * gfortran.h: Prototype for existing function, global_used. * resolve.c (resolve_global_procedure): New function to check global symbols for procedures. (resolve_call, resolve_function): Calls to this new function for non-contained and non-module procedures. * match.c (match_common): Add check for existing global symbol, creat one if none exists and emit error if there is a clash. * parse.c (global_used): Remove static and use the gsymbol name rather than the new_block name, so that the function can be called from resolve.c. (parse_block_data, parse_module, add_global_procedure): Improve checks for existing gsymbols. Emit error if already defined or if references were to another type. Set defined flag. PR fortran/PR24276 * trans-expr.c (gfc_conv_aliased_arg): New function called by gfc_conv_function_call that coverts an expression for an aliased component reference to a derived type array into a temporary array of the same type as the component. The temporary is passed as an actual argument for the procedure call and is copied back to the derived type after the call. (is_aliased_array): New function that detects an array reference that is followed by a component reference. (gfc_conv_function_call): Detect an aliased actual argument with is_aliased_array and convert it to a temporary and back again using gfc_conv_aliased_arg. 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * gfortran.dg/internal_references_1.f90: New test. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * gfortran.dg/global_references_1.f90: New test. * gfortran.dg/g77/19990905-1.f: Restore the error that there is a clash between the common block name and the name of a subroutine reference. PR fortran/PR24276 * gfortran.dg/aliasing_dummy_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/global_references_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_references_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/g77/19990905-1.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #11 from pault at gcc dot gnu dot org 2006-01-21 09:09 --- Subject: Bug 23308 Author: pault Date: Sat Jan 21 09:08:54 2006 New Revision: 110063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110063 Log: 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * decl.c (get_proc_name): If there is an existing symbol in the encompassing namespace, call errors if it is a procedure of the same name or the kind field is set, indicating a type declaration. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * decl.c (add_global_entry): New function to check for existing global symbol with this name and to create new one if none exists. (gfc_match_entry): Call add_global_entry before matching argument lists for subroutine and function entries. * gfortran.h: Prototype for existing function, global_used. * resolve.c (resolve_global_procedure): New function to check global symbols for procedures. (resolve_call, resolve_function): Calls to this new function for non-contained and non-module procedures. * match.c (match_common): Add check for existing global symbol, creat one if none exists and emit error if there is a clash. * parse.c (global_used): Remove static and use the gsymbol name rather than the new_block name, so that the function can be called from resolve.c. (parse_block_data, parse_module, add_global_procedure): Improve checks for existing gsymbols. Emit error if already defined or if references were to another type. Set defined flag. PR fortran/PR24276 * trans-expr.c (gfc_conv_aliased_arg): New function called by gfc_conv_function_call that coverts an expression for an aliased component reference to a derived type array into a temporary array of the same type as the component. The temporary is passed as an actual argument for the procedure call and is copied back to the derived type after the call. (is_aliased_array): New function that detects an array reference that is followed by a component reference. (gfc_conv_function_call): Detect an aliased actual argument with is_aliased_array and convert it to a temporary and back again using gfc_conv_aliased_arg. 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * gfortran.dg/internal_references_1.f90: New test. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * gfortran.dg/global_references_1.f90: New test. * gfortran.dg/g77/19990905-1.f: Restore the error that there is a clash between the common block name and the name of a subroutine reference. PR fortran/PR24276 * gfortran.dg/aliasing_dummy_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/global_references_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_references_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/g77/19990905-1.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug fortran/20881] should check interfaces for lgobal procedures
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-21 09:09 --- Subject: Bug 20881 Author: pault Date: Sat Jan 21 09:08:54 2006 New Revision: 110063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110063 Log: 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * decl.c (get_proc_name): If there is an existing symbol in the encompassing namespace, call errors if it is a procedure of the same name or the kind field is set, indicating a type declaration. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * decl.c (add_global_entry): New function to check for existing global symbol with this name and to create new one if none exists. (gfc_match_entry): Call add_global_entry before matching argument lists for subroutine and function entries. * gfortran.h: Prototype for existing function, global_used. * resolve.c (resolve_global_procedure): New function to check global symbols for procedures. (resolve_call, resolve_function): Calls to this new function for non-contained and non-module procedures. * match.c (match_common): Add check for existing global symbol, creat one if none exists and emit error if there is a clash. * parse.c (global_used): Remove static and use the gsymbol name rather than the new_block name, so that the function can be called from resolve.c. (parse_block_data, parse_module, add_global_procedure): Improve checks for existing gsymbols. Emit error if already defined or if references were to another type. Set defined flag. PR fortran/PR24276 * trans-expr.c (gfc_conv_aliased_arg): New function called by gfc_conv_function_call that coverts an expression for an aliased component reference to a derived type array into a temporary array of the same type as the component. The temporary is passed as an actual argument for the procedure call and is copied back to the derived type after the call. (is_aliased_array): New function that detects an array reference that is followed by a component reference. (gfc_conv_function_call): Detect an aliased actual argument with is_aliased_array and convert it to a temporary and back again using gfc_conv_aliased_arg. 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * gfortran.dg/internal_references_1.f90: New test. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * gfortran.dg/global_references_1.f90: New test. * gfortran.dg/g77/19990905-1.f: Restore the error that there is a clash between the common block name and the name of a subroutine reference. PR fortran/PR24276 * gfortran.dg/aliasing_dummy_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/global_references_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_references_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/g77/19990905-1.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20881
[Bug fortran/25710] accepts "call" to function
--- Comment #1 from pault at gcc dot gnu dot org 2006-01-21 09:09 --- Subject: Bug 25710 Author: pault Date: Sat Jan 21 09:08:54 2006 New Revision: 110063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110063 Log: 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * decl.c (get_proc_name): If there is an existing symbol in the encompassing namespace, call errors if it is a procedure of the same name or the kind field is set, indicating a type declaration. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * decl.c (add_global_entry): New function to check for existing global symbol with this name and to create new one if none exists. (gfc_match_entry): Call add_global_entry before matching argument lists for subroutine and function entries. * gfortran.h: Prototype for existing function, global_used. * resolve.c (resolve_global_procedure): New function to check global symbols for procedures. (resolve_call, resolve_function): Calls to this new function for non-contained and non-module procedures. * match.c (match_common): Add check for existing global symbol, creat one if none exists and emit error if there is a clash. * parse.c (global_used): Remove static and use the gsymbol name rather than the new_block name, so that the function can be called from resolve.c. (parse_block_data, parse_module, add_global_procedure): Improve checks for existing gsymbols. Emit error if already defined or if references were to another type. Set defined flag. PR fortran/PR24276 * trans-expr.c (gfc_conv_aliased_arg): New function called by gfc_conv_function_call that coverts an expression for an aliased component reference to a derived type array into a temporary array of the same type as the component. The temporary is passed as an actual argument for the procedure call and is copied back to the derived type after the call. (is_aliased_array): New function that detects an array reference that is followed by a component reference. (gfc_conv_function_call): Detect an aliased actual argument with is_aliased_array and convert it to a temporary and back again using gfc_conv_aliased_arg. 2005-01-21 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25124 PR fortran/25625 * gfortran.dg/internal_references_1.f90: New test. PR fortran/20881 PR fortran/23308 PR fortran/25538 PR fortran/25710 * gfortran.dg/global_references_1.f90: New test. * gfortran.dg/g77/19990905-1.f: Restore the error that there is a clash between the common block name and the name of a subroutine reference. PR fortran/PR24276 * gfortran.dg/aliasing_dummy_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/global_references_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_references_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/g77/19990905-1.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25710
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #15 from laurent at guerby dot net 2006-01-21 09:32 --- 4.2 fails on amd64-linux as of Fri Jan 20 20:40:28 UTC 2006 (revision 110036) http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01071.html RUN cdd2a02 ,.,. CDD2A02 ACATS 2.5 06-01-23 01:01:16 CDD2A02 Check that the Read, Write, Input, and Output attributes are inherited for untagged derived types. * CDD2A02 Inherited Input and Output are not inverses of each other - 4. CDD2A02 FAILED . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/25899] New: [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
On 4.2 as of Fri Jan 20 20:40:28 UTC 2006 (revision 110036) RUN c34006a ,.,. C34006A ACATS 2.5 06-01-21 00:50:22 C34006A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED (IMPLICITLY) FOR DERIVED RECORD TYPES WITHOUT DISCRIMINANTS AND WITH NON-LIMITED COMPONENT TYPES. * C34006A INCORRECT :=. * C34006A INCORRECT QUALIFICATION. * C34006A INCORRECT SELF CONVERSION. * C34006A INCORRECT CONVERSION TO PARENT. * C34006A INCORRECT SELECTION (VALUE). C34006A FAILED . RUN cc1226b ,.,. CC1226B ACATS 2.5 06-01-21 01:19:31 CC1226B CHECK, FOR A FORMAL NONLIMITED PRIVATE TYPE THAT ALL ALLOWABLE OPERATIONS ARE IMPLICITLY DECLARED. raised CONSTRAINT_ERROR : cc1226b.adb:155 discriminant check failed These tests were passing on 4.2 as of Thu Jan 12 22:55:03 UTC 2006 (revision 109649). Note: works on amd64-linux. -- Summary: [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug ada/25900] New: [4.2 Regression] ACATS ICE cxac0004 in set_value_range, at tree-vrp.c:161 on x86-linux
On 4.2 as of Fri Jan 20 20:40:28 UTC 2006 (revision 110036): +===GNAT BUG DETECTED==+ | 4.2.0 20060120 (experimental) (i686-pc-linux-gnu) GCC error: | | in set_value_range, at tree-vrp.c:161| | Error detected at cxac004.adb:310:5 | It was working as of Thu Jan 12 22:55:03 UTC 2006 (revision 109649). Note: it works on amd64-linux. -- Summary: [4.2 Regression] ACATS ICE cxac0004 in set_value_range, at tree-vrp.c:161 on x86-linux Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25900
[Bug libstdc++/25896] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #4 from pcarlini at suse dot de 2006-01-21 10:10 --- This is a general issue in the standard described in DR 526 http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html and prompted by libstdc++/17012 too. I guess the best we can do, is SUSPENDING both the PRs and making sure DR 526 is discussed as soon as possible by the LWG. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-21 10:10:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug libstdc++/25896] hash_map::erase, unordered_map::erase fail if key is inside the table
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #10 from pcarlini at suse dot de 2006-01-21 10:12 --- Now DR 526. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Summary|std::list's function, |[DR 526] std::list's |remove, looks like it is|function, remove, looks like |reading memory that has been|it is reading memory that |freed. |has been freed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug fortran/25901] New: [gfortran, 4.2.0 regression] overloaded function is rejected
Current mainline gfortran rejects the code below: module general_time implicit none type gnsec integer :: int end type gnsec interface operator(+) module procedure & gn_addsec_int_post, gn_addsec_int_pre end interface contains function gn_addsec_int_pre(interval, sec) result(isec) integer, intent(in) :: interval type(gnsec), intent(in) :: sec type(gnsec) :: isec isec = gn_addsec_int_post(sec, interval) end function gn_addsec_int_pre function gn_addsec_int_post(sec, interval) result(seci) type(gnsec), intent(in) :: sec integer, intent(in) :: interval type(gnsec) :: seci seci%int = sec%int + interval end function gn_addsec_int_post end module general_time [EMAIL PROTECTED]:~/tmp> gfortran -v -c bug2.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/martin/software/gcc/configure --with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr --prefix=/home/martin/software/ugcc --enable-languages=c++,fortran --enable-checking=release Thread model: posix gcc version 4.2.0 20060121 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 bug2.f90 -quiet -dumpbase bug2.f90 -mtune=generic -auxbase bug2 -version -o /tmp/ccpO6EFZ.s GNU F95 version 4.2.0 20060121 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060121 (experimental). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128005 In file bug2.f90:23 function gn_addsec_int_post(sec, interval) result(seci) 1 In file bug2.f90:10 gn_addsec_int_post, gn_addsec_int_pre 2 Error: Procedure 'gn_addsec_int_post' at (1) is already defined at (2) This code was compiled without problems by gfortran a few days ago. -- Summary: [gfortran, 4.2.0 regression] overloaded function is rejected Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25901
[Bug target/21344] Libgcc file name not returned correctly
--- Comment #1 from drow at gcc dot gnu dot org 2006-01-21 16:18 --- I tested this with both HEAD (to become 4.2.0) and the 4.0 branch (4.0.3). It worked in both cases. My guess would be that either your arm-thumb-elf-gcc was built with multilibs disabled, or else the thumb libgcc is missing from its normal install location, forcing GCC to fall back to the default copy. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21344
[Bug c++/14167] Unneeded C++ types are output in debug info due to use of static constants
--- Comment #3 from drow at gcc dot gnu dot org 2006-01-21 16:27 --- I don't have G++ 3.4 handy at the moment. 3.3 emits about three and a half times as large of a .debug_info section as 4.0, however, so I believe this is fixed. There's still lots of unneeded debug information output, but I believe I've got another open PR describing that. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14167
[Bug c++/14167] Unneeded C++ types are output in debug info due to use of static constants
--- Comment #4 from drow at gcc dot gnu dot org 2006-01-21 16:37 ---
Oops, not so clear after all.
Debug information for Class1 is no longer emitted, but debug information for
Class1::var1 is still emitted. It just doesn't trigger the output of the
containing class any more.
If I add a real use of var1:
class Class1 {
public:
static const int var1 = 1;
static const int var2 = var1;
};
class Class2 {
static const int var1 = 1;
static const int var2 = 1;
};
int main(void)
{
return Class1::var1;
}
Still no change. We get a declaration for var1, but no definition for it, and
not even a declaration of the containing class. It looks like this:
<1><244>: Abbrev Number: 5 (DW_TAG_variable)
DW_AT_name: var1
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_MIPS_linkage_name: _ZN6Class14var1E
DW_AT_type: <219>
DW_AT_external: 1
DW_AT_declaration : 1
DW_AT_const_value : 1
That's pretty useless. It doesn't let a debugger print Class1::var1.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14167
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2006-01-21 17:27 --- Subject: Re: [gfortran, 4.1.0 regression] Arithmetic overflow during compilation On Sat, Jan 21, 2006 at 08:49:26AM -, martin at mpa-garching dot mpg dot de wrote: > > Unfortunately I can reproduce it with GMP 4.1.4 now :( > This is on an Athlon64 with Suse 10.0, using the GMP 4.1.4 coming with the > distribution. > > What do we do? > Contact SuSe. This isn't a gfortran problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug libgomp/25877] [4.2 Regression] team.c:269: warning: implicit declaration of function 'alloca'
--- Comment #3 from sje at gcc dot gnu dot org 2006-01-21 17:57 --- Subject: Bug 25877 Author: sje Date: Sat Jan 21 17:57:01 2006 New Revision: 110068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110068 Log: PR libgomp/25877 * configure.ac: Remove check for alloca.h. * configure: Regenerate. * config.h.in: Regenerate. * libgomp.h: define gomp_alloca to be __builtin_alloca. * team.c: Remove use of alloca.h. Call gomp_alloca instead of alloca. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config.h.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/libgomp.h trunk/libgomp/team.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25877
[Bug c++/25894] [3.4/4.0/4.1/4.2 Regression] conditional operator operating on derived / base pointers appears incorrect
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-21 18:05 --- The code in the original description is invalid. "x" cannot appear in a constant-expression because its initializer is not an integral constant expression, because the initializer contains casts to pointer types. See [expr.const]. The actual value given to "x" is a separate issue, so PR 25895 remains open. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
--- Comment #1 from mmitchel at gcc dot gnu dot org 2006-01-21 18:49 --- This regression comes from the changes that were made (by Jason, I believe) to use base class FIELD_DECLs to perform casts from derived to base classes, rather than just pointer arithmetic. In build_base_path, we decide not to generate an explicit test for NULL because we've noticed that the base class is at offset zero relative to the derived class, and therefore we know that the conversion will be a no-op. As an optimization, we avoid generating the NULL test. We end up with: ADDR_EXPR (COMPONENT_REF (INDIRECT_REF 0) (FIELD_DECL base)) which c_common_truthvalue_conversions "knows" must be non-NULL. I believe that in the case that we know that the conversion is a no-op, we should just return a NOP_EXPR, rather than going through the fields. This is a P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2006-01-21 18:49:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
-- mmitchel at gcc dot gnu dot org changed: 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=25895
[Bug c++/11856] unsigned warning in template
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-21 20:38 --- -Wno-always-true does NOT disable this warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug libgomp/25877] [4.2 Regression] team.c:269: warning: implicit declaration of function 'alloca'
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-21 20:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25877
[Bug ada/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug ada/25900] [4.2 Regression] ACATS ICE cxac0004 in set_value_range, at tree-vrp.c:161 on x86-linux
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, law at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25900
[Bug c++/23628] Typeinfo comparison code easily breaks shared libs
--- Comment #26 from rjohnson at dogstar-interactive dot com 2006-01-21 21:02 --- I just got bit by this using gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) (powerpc) It's just my $.02 from the gallery, but that address comparison in the type_info::oprator==() implementation looks suspect. Stroustrup (3rd edition, $15.4.4) specifically says: It is _not_ guaranteed that there is only one type_info object for each type in the system. and then he goes on to call out dynamically linked libraries as a particular case. If folks are interested, I can propose a relatively inexpensive (i.e. non-strcmp) runtime strawman for consideration. -- rjohnson at dogstar-interactive dot com changed: What|Removed |Added CC||rjohnson at dogstar- ||interactive dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628
[Bug c++/23628] Typeinfo comparison code easily breaks shared libs
--- Comment #27 from gdr at cs dot tamu dot edu 2006-01-21 21:45 --- Subject: Re: Typeinfo comparison code easily breaks shared libs "rjohnson at dogstar-interactive dot com" <[EMAIL PROTECTED]> writes: | I just got bit by this using |gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) (powerpc) | | It's just my $.02 from the gallery, but that address comparison in the | type_info::oprator==() implementation looks suspect. Stroustrup (3rd edition, | $15.4.4) specifically says: | | It is _not_ guaranteed that there is only one type_info object for each type in | the system. | | and then he goes on to call out dynamically linked libraries as a particular | case. | | If folks are interested, I can propose a relatively inexpensive (i.e. | non-strcmp) runtime strawman for consideration. Please look more carefully at the real implementation and look up the archive. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628
[Bug ada/25902] New: GNAT Bug Box, Assert_Failure in sem when using default box <> for invisible record component
(Same with 4.1.0 20060119) $ gnatmake -gnat05 rooms.adb gcc -c -gnat05 rooms.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060121 (experimental) (i686-pc-linux-gnu) Assert_Failure sem.adb:549| | Error detected at rooms.adb:5:43 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. rooms.adb rooms.ads doors.ads compilation abandoned gnatmake: "rooms.adb" compilation error $ package Doors is type DOOR is tagged private; private type DOOR is tagged record is_opened: BOOLEAN := False; end record; end Doors; with Doors; package Rooms is type ROOM is tagged record the_door: Doors.DOOR; end record; function make return ROOM; end Rooms; package body Rooms is function make return ROOM is begin return ROOM'(the_door => Doors.DOOR'(is_opened => <>)); end make; end Rooms; -- Summary: GNAT Bug Box, Assert_Failure in sem when using default box <> for invisible record component Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de 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=25902
[Bug ada/25902] GNAT Bug Box, Assert_Failure in sem when using default box <> for invisible record component
--- Comment #1 from bauhaus at futureapps dot de 2006-01-21 22:00 --- works in: 3.4.5 20050524 (prerelease) for GNAT GPL 2005 (20050614) (by AdaCore) does not work (Bug box, too): 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) (i486-pc-linux-gnu) -- bauhaus at futureapps dot de changed: What|Removed |Added Known to fail||4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25902
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #11 from mec at google dot com 2006-01-21 22:04 --- You can make this visible at the C++ program level with a Key class that has a signature field. Init the signature in the constructor, clear the signature in the destructor, and check the signature in operator==. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug c++/12076] gcov misreports coverage of return statement [NVR]
--- Comment #13 from jbuck at welsh-buck dot org 2006-01-21 22:33 --- Subject: Re: gcov misreports coverage of return statement [NVR] On Thu, 2005-10-27 at 01:41 +, reddy at pixar dot com wrote: > > --- Comment #12 from reddy at pixar dot com 2005-10-27 01:41 --- > Having code coverage emit a "-" instead of "#" in this case sounds > appropriate and would certainly solve the problem for me. > > Is there a way to workaround this issue by reorganizing code, or something > else, so that I can fool the NVR smarts into not getting invoked in this > particular case? The -fno-elide-constructors flag helps; it forces explicit copy constructor calls, and that seems to get rid of most of the bogons -- but apparently not all of them -- I'll look further, but I think sometimes the initializer for a base class gets optimized in a way that results in a false ## flagging. Still, if you're having this trouble, start with that flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12076
[Bug c++/17655] [3.4 regression] ICE with using a C99 initializer in an if-condition
--- Comment #16 from gdr at gcc dot gnu dot org 2006-01-21 22:44 --- Fixed in 4.0.0. and higher. Fill no fix in 3.4.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|3.4.6 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17655
[Bug c++/24072] [3.4 Regression] diagnostics, oh my!
--- Comment #3 from gdr at gcc dot gnu dot org 2006-01-21 22:46 --- Fixed in 4.0.0 and higher, won't fix in 3.4.6. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|3.4.6 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24072
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-21 22:46 --- Zdenek, are you working on a patch for this? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug c++/25904] New: ICE on invalid code in switch stmt
Using gcc (GCC) 4.1.0 20051026 (experimental),
the following code will generate an ICE.
Sorry, I currently don't have the time to test the latest version of
gcc.
---
void foo()
{
int t;
switch(t)
{
case 0: A();
case 1: A();
}
}
---
test.cc: In function 'void foo()':
test.cc:6: error: 'A' was not declared in this scope
test.cc:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in decl_jump_unsafe, at cp/decl.c:2153
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Regards,
Wolfgang
--
Summary: ICE on invalid code in switch stmt
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wwieser at gmx dot de
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=25904
[Bug ada/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #1 from laurent at guerby dot net 2006-01-21 23:11 --- c34006a and cc1226b were passing on r109969 and are failing since r109971 r109971 | hubicka | 2006-01-19 18:10:24 +0100 (Thu, 19 Jan 2006) | 36 lines * invoke.texi (generic): Document (i686) Update. * config.gcc: Make x86_64-* and i686-* default to generic tunning. ... -- laurent at guerby dot net changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug ada/25902] GNAT Bug Box, Assert_Failure in sem when using default box <> for invisible record component
--- Comment #2 from laurent at guerby dot net 2006-01-21 23:20 --- Confirmed. $ gcc -c -gnat05 rooms.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060120 (experimental) (i686-pc-linux-gnu) Assert_Failure sem.adb:549| | Error detected at rooms.adb:6:43 | -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-21 23:20:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25902
[Bug middle-end/25905] New: [4.2 regression] ICE in expand_compound_operation
$ ./xgcc -B./ unwind-dw2-fde-glibc.i -S -O -v Reading specs from ./specs Target: m68k-linux Configured with: ../gcc/configure --prefix=/usr/local/m68k-linux --host=powerpc-linux --target=m68k-linux --with-sysroot=/usr/local/m68k-linux/m68k-linux/sys-root --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-languages=c,c++,fortran,java,objc --no-create --no-recursion Thread model: posix gcc version 4.2.0 20060121 (experimental) ./cc1 -fpreprocessed unwind-dw2-fde-glibc.i -quiet -dumpbase unwind-dw2-fde-glibc.i -auxbase unwind-dw2-fde-glibc -O -version -o unwind-dw2-fde-glibc.s GNU C version 4.2.0 20060121 (experimental) (m68k-linux) compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0ad6bd3654ebd3f56f26d23ad96d1796 ../../gcc/gcc/unwind-dw2-fde.c: In function ‘fde_single_encoding_compare’: ../../gcc/gcc/unwind-dw2-fde.c:350: internal compiler error: in expand_compound_operation, at combine.c:5644 Caused by: r109961 | bonzini | 2006-01-19 15:54:57 +0100 (Do, 19 Jan 2006) | 13 lines 2006-01-19 Paolo Bonzini <[EMAIL PROTECTED]> * combine.c (try_combine): Do not worry about MEMs wrapped by USEs. (expand_compound_operation, expand_field_assignment): Fail if the bit lengths of an extract operation are out of range. (make_extraction): Compute wanted_inner_mode based on the position and length of the extraction. Make it extraction_mode for non-constant positions, and do not modify offset in that case. When generating a new MEM, use a mode that can hold the extraction while keeping correct alignment. Remove code that supported MEMs wrapped by USEs. (simplify_shift_const_1, force_to_mode) : Remove. -- Summary: [4.2 regression] ICE in expand_compound_operation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: m68k-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25905
[Bug middle-end/25905] [4.2 regression] ICE in expand_compound_operation
--- Comment #1 from schwab at suse dot de 2006-01-21 23:25 --- Created an attachment (id=10696) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10696&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25905
[Bug c++/16190] -Wnon-virtual-dtor, in -Wall, silenced only by pessimizing code
--- Comment #22 from gdr at gcc dot gnu dot org 2006-01-21 23:28 --- Working on a patch. -- gdr at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-06-25 14:16:04 |2006-01-21 23:28:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16190
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|ada |target Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2006-01-21 23:33:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug middle-end/25905] [4.2 regression] ICE in expand_compound_operation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25905
[Bug c++/25904] ICE on invalid code in switch stmt
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 23:42 --- *** This bug has been marked as a duplicate of 24582 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25904
[Bug c++/24582] [4.0/4.1 regression] ICE in decl_jump_unsafe
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-21 23:42 --- *** Bug 25904 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||wwieser at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
[Bug middle-end/25905] [4.2 regression] ICE in expand_compound_operation
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 23:44 --- I think this is related to PR 25890 which is reproducible on x86_64-linux-gnu also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25890 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25905
[Bug c++/25858] [4.0/4.1/4.2 regression] ICE on forgotten ":" in definition of derived class
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-22 00:41 --- Subject: Bug 25858 Author: mmitchel Date: Sun Jan 22 00:40:56 2006 New Revision: 110082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110082 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/conv2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor7.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/crash44.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25858
[Bug c++/25856] [4.0/4.1/4.2 regression] ICE defining destructor for incomplete class
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-22 00:41 --- Subject: Bug 25856 Author: mmitchel Date: Sun Jan 22 00:40:56 2006 New Revision: 110082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110082 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/conv2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor7.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/crash44.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25856
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-22 00:41 --- Subject: Bug 25895 Author: mmitchel Date: Sun Jan 22 00:40:56 2006 New Revision: 110082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110082 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/conv2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/dtor7.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/crash44.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/class.c branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug c++/25856] [4.0/4.1/4.2 regression] ICE defining destructor for incomplete class
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-22 00:42 --- Subject: Bug 25856 Author: mmitchel Date: Sun Jan 22 00:41:58 2006 New Revision: 110083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110083 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/conv2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor7.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash44.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25856
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-22 00:42 --- Subject: Bug 25895 Author: mmitchel Date: Sun Jan 22 00:41:58 2006 New Revision: 110083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110083 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/conv2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor7.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash44.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug c++/25858] [4.0/4.1/4.2 regression] ICE on forgotten ":" in definition of derived class
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-22 00:42 --- Subject: Bug 25858 Author: mmitchel Date: Sun Jan 22 00:41:58 2006 New Revision: 110083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110083 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/conv2.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/dtor7.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash44.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25858
[Bug c++/25856] [4.0/4.1/4.2 regression] ICE defining destructor for incomplete class
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-22 00:42 --- Subject: Bug 25856 Author: mmitchel Date: Sun Jan 22 00:42:40 2006 New Revision: 110084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110084 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/conv2.C trunk/gcc/testsuite/g++.dg/parse/dtor7.C trunk/gcc/testsuite/g++.dg/template/crash44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25856
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-22 00:42 --- Subject: Bug 25895 Author: mmitchel Date: Sun Jan 22 00:42:40 2006 New Revision: 110084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110084 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/conv2.C trunk/gcc/testsuite/g++.dg/parse/dtor7.C trunk/gcc/testsuite/g++.dg/template/crash44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug c++/25858] [4.0/4.1/4.2 regression] ICE on forgotten ":" in definition of derived class
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-22 00:42 --- Subject: Bug 25858 Author: mmitchel Date: Sun Jan 22 00:42:40 2006 New Revision: 110084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110084 Log: PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. PR c++/25856 * decl.c (begin_destructor_body): Robustify. PR c++/25858 * parser.c (cp_parser_direct_declarator): Robustify. PR c++/25895 * g++.dg/inherit/conv2.C: New test. PR c++/25856 * g++.dg/parse/dtor7.C: New test. PR c++/25858 * g++.dg/template/crash44.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/conv2.C trunk/gcc/testsuite/g++.dg/parse/dtor7.C trunk/gcc/testsuite/g++.dg/template/crash44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25858
[Bug fortran/24327] Does not detect duplicate symbol names in contains block
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-22 00:46 --- It looks like one or more of pault's patchs has fixed this problem. kargl[209] gfc4x -c pr24327.f90 In file pr24327.f90:4 function foo () 1 In file pr24327.f90:2 real :: foo 2 Error: Procedure 'foo' at (1) has an explicit interface and must not have attributes declared at (2) Adding external attribute I get kargl[214] gfc4x -c pr24327.f90 In file pr24327.f90:4 function foo () 1 In file pr24327.f90:2 real, external :: foo 2 Error: Procedure 'foo' at (1) has an explicit interface and must not have attri butes declared at (2) In file pr24327.f90:4 function foo () 1 Error: EXTERNAL attribute conflicts with FUNCTION attribute in 'foo' at (1) In file pr24327.f90:5 end function foo 1 Error: Expecting END PROGRAM statement at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24327
[Bug c++/25908] New: Multiple definitions of symbol vtables
I use gcc (GCC) 4.2.0 20060120 to compile Cactus, a large piece of code combining C, C++, and Fortran. I receive many errors from the linker like /usr/bin/ld: multiple definitions of symbol typeinfo for MPI::Op /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_Carpet.a(helpers.cc.o) definition of typeinfo for MPI::Opin section (__DATA,__const) /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_CarpetAdaptiveRegrid.a(CAR.cc.o) definition of typeinfo for MPI::Opin section (__DATA,__const) or /usr/bin/ld: multiple definitions of symbol vtable for MPI::Op /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_Carpet.a(helpers.cc.o) definition of vtable for MPI::Opin section (__DATA,__const) /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_CarpetAdaptiveRegrid.a(CAR.cc.o) definition of vtable for MPI::Opin section (__DATA,__const) (Note that the error messages seem run-together; e.g. "MPI::OPin" seems to refer to the class "MPI::Op", which is located IN a certain section.) These errors are not there with gcc (GCC) 4.2.0 20051129. The code also works fine on many other architectures. But with C++, I am not sure what the reason is. I have looked on the web, and the gcc PR "[Bug c++/16218] Link problems with inline virtual function in multiple translation units" seems similar. At that time, it apparently was an error in gcc that caused this problem. I use the linker /usr/bin/ld Apple Computer, Inc. version cctools-590.18.obj~10 and these C++ classes are defined in LAM MPI 7.0.6-11, which I installed via fink. -- Summary: Multiple definitions of symbol vtables Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.4.0 GCC host triplet: powerpc-apple-darwin8.4.0 GCC target triplet: powerpc-apple-darwin8.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
[Bug c++/25858] [4.0/4.1/4.2 regression] ICE on forgotten ":" in definition of derived class
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-22 00:51 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25858
[Bug c++/25856] [4.0/4.1/4.2 regression] ICE defining destructor for incomplete class
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-22 00:52 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25856
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-22 00:52 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug fortran/25685] Accepts invalid code for Fortran 90
--- Comment #1 from kargl at gcc dot gnu dot org 2006-01-22 00:56 --- Andrew, Are you sure? NAG's compiler compiles the code, as does gfortran. Lahey's checker when I gave it the code gives Lahey/Fujitsu Fortran 95 Source Check Output Compiling program unit a at line 1: Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90. Compiling file SOURCE.F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25685
[Bug fortran/25685] Accepts invalid code for Fortran 90
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-22 01:03 --- (In reply to comment #1) > Andrew, > Are you sure? NAG's compiler compiles the code, as does gfortran. > Lahey's checker when I gave it the code gives > Lahey/Fujitsu Fortran 95 Source Check Output This was from Lahey's Fortran 90 compiler. I think it is valid F95 but invalid F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25685
[Bug fortran/24554] internal compiler error
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-22 01:06 --- Closing as fixed. The (duplicate?) PR pointed to by Richard has been fixed, and the originator of this bug report has not supplied the code as requested by Andrew on 10/30/05. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24554
[Bug rtl-optimization/25798] [4.2 Regression] ICE with -O1 -fmodulo-sched -ftracer
--- Comment #3 from drab at kepler dot fjfi dot cvut dot cz 2006-01-22 01:16 --- The bug seems to be fixed. (Tested on gcc version 4.2.0 20060121 (experimental)). Perhaps the fix of bug 25799 fixed this bug. Can anyone confirm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25798
[Bug rtl-optimization/25798] [4.2 Regression] ICE with -O1 -fmodulo-sched -ftracer
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-22 01:24 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25798
[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory
--- Comment #28 from pinskia at gcc dot gnu dot org 2006-01-22 01:26 --- (In reply to comment #27) > OK, I think I see it now. The only explanation is that the memset doesn't have > register arguments. Then it IS there. Is that the case? Yes the memset is there, we just had not called it yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
[Bug c++/16190] -Wnon-virtual-dtor, in -Wall, silenced only by pessimizing code
--- Comment #23 from gdr at gcc dot gnu dot org 2006-01-22 02:56 --- Fixed in 4.2.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16190
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
--- Comment #19 from gdr at gcc dot gnu dot org 2006-01-22 03:00 --- Fixed in 4.0.0 and higher. Won't fix for 3.4.6 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Target Milestone|3.4.6 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug c++/16572] [3.4 regression] Wrong filename/line number were reported by g++ in inlining's warning messages
--- Comment #6 from gdr at gcc dot gnu dot org 2006-01-22 03:08 --- Fixed in 4.0.0 and higher. Won't fix for 3.4.6 -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|3.4.6 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16572
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
--- Comment #20 from gdr at gcc dot gnu dot org 2006-01-22 03:13 --- fixed. Not suspended. Silly bugzilla. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
--- Comment #6 from gdr at gcc dot gnu dot org 2006-01-22 03:43 --- (In reply to comment #5) > Also, it should detect any scalar member variables that are not assigned to in > any way in the constructor. Agreed. However -Wunitialized is taken over by the middle-end. This is one more case where I agre with Mark Mitchell that the middl-end should not try those things. Long term, we should move such warnings to the front-end. Yes I know, that is not a universally held opinon. -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
[Bug c++/17122] Unable to compile friend operator within template
--- Comment #10 from relf at os2 dot ru 2006-01-22 04:15 --- Works fine on g++ 3.3.6 but fails on g++ 3.4.5 and 4.0.3. Must be a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17122
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #3 from hjl at lucon dot org 2006-01-22 04:36 --- I can't duplicate this. See: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01110.html -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #4 from hjl at lucon dot org 2006-01-22 07:03 --- Here is the result on Linux/ia32: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01114.html -- hjl at lucon dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug libfortran/25835] Segfault or Bad Address error on unformatted sequential READ
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-01-22 07:45 --- In the following case, the second read is failing to read anything and gives no error, giving the impression that it is working if you don't look at the data. Works for data size of 2044 or less. This bug is ugly. Works fine if you get rid of the first read, which leads me to believe we are not cleaning up correctly after an end error condition. (I have been down more than one trail on this already so who knows) :) integer data(2045) data=5 open(unit=11,form='unformatted') write(11)data read(11,end=1000 )data call abort() 1000 continue backspace 11 backspace 11 data = 0 read(11)data print *, data close(11) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25835
