[Bug c++/18803] [4.0 regression] rejects access to operator() in template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 08:36 --- Subject: Bug 18803 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 08:36:10 Modified files: gcc/cp : ChangeLog call.c class.c cp-tree.h cvt.c decl.c decl2.c except.c init.c parser.c pt.c rtti.c semantics.c typeck.c typeck2.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: operator5.C Log message: cp: PR c++/18803 * cp-tree.h (REFERENCE_REF_P): New. (CPTI_TYPE_INFO_TYPE): Rename to ... (CPTI_CONST_TYPE_INFO_TYPE): ... here. (CPTI_TYPE_INFO_REF_TYPE): Remove. (type_info_type_node): Rename to ... (const_type_info_type_node): ... here. (type_info_ref_type): Remove. * call.c (build_user_type_conversion): Reformat. (resolve_args): Do not convert_from_reference. (build_object_call): Call convert_from_reference. (prep_operand): Do not convert_from_reference. (build_new_method_call): Likewise. * class.c (build_vfield_ref): Likewise. * cvt.c (convert_to_reference): Likewise. (convert_from_reference): Build INDIRECT_REF here, not with build_indirect_ref. (convert_force): Do not convert_from_reference. (build_expr_type_conversion): Likewise. * decl.c (grok_reference_init): Likewise. * decl2.c (delete_sanity): Likewise. * except.c (initialize_handler_parm): Use POINTER_TYPE_P. * init.c (build_dtor_call): Do not convert_from_reference. * parser.c (cp_parser_template_argument): Unwrap indirected reference. Allow TEMPLATE_PARM_INDEX as an object parm. * pt.c (tsubst_copy_and_build) case INDIRECT_REF: Use convert_from_reference, if indicated. case CALL_EXPR: Do not convert_from_reference. case PARM_DECL, VAR_DECL: Convert_from_reference if needed. (tsubst_initializer_list): Do not convert_from_reference. * rtti.c (init_rtti_processing): Adjust node creation. (throw_bad_typeid): Use const_type_info_type_node. Do not convert_from_reference. (typeid_ok_p): Use const_type_info_type_node. (build_typeid, get_typeid): Always return type_info typed node. (build_dynamic_cast_1): Dont convert_from_reference. Refactor. * semantics.c (finish_stmt_expr_expr): Do not convert_from_reference. (finish_id_expression): Convert_from_reference as appropriate. * typeck.c (decay_conversion): Do not convert_from_reference. (finish_class_member_access_expr): Likewise. (build_indirect_ref): Use POINTER_TYPE_P. (convert_arguments): Do not convert_from_reference. (build_modify_expr): Likewise. (convert_for_initialization): Likewise. * typeck2.c (build_x_arrow): Likewise. testsuite: PR c++/18803 * g++.dg/template/operator5.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4519r2=1.4520 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.521r2=1.522 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gccr1=1.691r2=1.692 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1079r2=1.1080 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gccr1=1.172r2=1.173 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1338r2=1.1339 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.759r2=1.760 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/except.c.diff?cvsroot=gccr1=1.177r2=1.178 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gccr1=1.402r2=1.403 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.289r2=1.290 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.955r2=1.956 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gccr1=1.204r2=1.205 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gccr1=1.451r2=1.452 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gccr1=1.600r2=1.601 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck2.c.diff?cvsroot=gccr1=1.179r2=1.180 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4721r2=1.4722 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/operator5.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
[Bug c++/18803] [4.0 regression] rejects access to operator() in template
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-08 08:40 --- 2004-12-08 Nathan Sidwell [EMAIL PROTECTED] PR c++/18803 * cp-tree.h (REFERENCE_REF_P): New. (CPTI_TYPE_INFO_TYPE): Rename to ... (CPTI_CONST_TYPE_INFO_TYPE): ... here. (CPTI_TYPE_INFO_REF_TYPE): Remove. (type_info_type_node): Rename to ... (const_type_info_type_node): ... here. (type_info_ref_type): Remove. * call.c (build_user_type_conversion): Reformat. (resolve_args): Do not convert_from_reference. (build_object_call): Call convert_from_reference. (prep_operand): Do not convert_from_reference. (build_new_method_call): Likewise. * class.c (build_vfield_ref): Likewise. * cvt.c (convert_to_reference): Likewise. (convert_from_reference): Build INDIRECT_REF here, not with build_indirect_ref. (convert_force): Do not convert_from_reference. (build_expr_type_conversion): Likewise. * decl.c (grok_reference_init): Likewise. * decl2.c (delete_sanity): Likewise. * except.c (initialize_handler_parm): Use POINTER_TYPE_P. * init.c (build_dtor_call): Do not convert_from_reference. * parser.c (cp_parser_template_argument): Unwrap indirected reference. Allow TEMPLATE_PARM_INDEX as an object parm. * pt.c (tsubst_copy_and_build) case INDIRECT_REF: Use convert_from_reference, if indicated. case CALL_EXPR: Do not convert_from_reference. case PARM_DECL, VAR_DECL: Convert_from_reference if needed. (tsubst_initializer_list): Do not convert_from_reference. * rtti.c (init_rtti_processing): Adjust node creation. (throw_bad_typeid): Use const_type_info_type_node. Do not convert_from_reference. (typeid_ok_p): Use const_type_info_type_node. (build_typeid, get_typeid): Always return type_info typed node. (build_dynamic_cast_1): Dont convert_from_reference. Refactor. * semantics.c (finish_stmt_expr_expr): Do not convert_from_reference. (finish_id_expression): Convert_from_reference as appropriate. * typeck.c (decay_conversion): Do not convert_from_reference. (finish_class_member_access_expr): Likewise. (build_indirect_ref): Use POINTER_TYPE_P. (convert_arguments): Do not convert_from_reference. (build_modify_expr): Likewise. (convert_for_initialization): Likewise. * typeck2.c (build_x_arrow): Likewise. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
[Bug c++/18672] [4.0 Regression] Segfault with simple template code
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-08 08:45 --- PR c++/18672 * gimplify.c (canonicalize_addr_expr): Cope with array of incomplete type. (gimplify_conversion): Remove redundant checks. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18672
[Bug libstdc++/18882] New: wrong results of pow( complexlong double(2, 1), odd integer )
-- Summary: wrong results of pow( complexlong double(2, 1), odd integer ) Product: gcc Version: 3.3.1 Status: UNCONFIRMED Severity: critical Priority: P1 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikulik at physics dot muni dot cz CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug c++/18672] [4.0 Regression] Segfault with simple template code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 08:48 --- Subject: Bug 18672 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 08:48:01 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: array1.C Log message: .: PR c++/18672 * gimplify.c (canonicalize_addr_expr): Cope with array of incomplete type. (gimplify_conversion): Remove redundant checks. testsuite: PR c++/18672 * g++.dg/opt/array1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6747r2=2.6748 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.91r2=2.92 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4722r2=1.4723 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/array1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18672
[Bug tree-optimization/18880] DSE is not doing its job for global variables
-- What|Removed |Added CC||law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug libstdc++/18882] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From mikulik at physics dot muni dot cz 2004-12-08 08:53 --- Created an attachment (id=7704) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7704action=view) for given x and n=1,2,3,4,5,... , print pow(x, n) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug target/18713] Large program size due to uninitialised global data
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-08 08:56 --- Bugs for gcc 3.2.3 are not going to be fixed. Are you seeing this problem with more recent versions of GCC as well? -- What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Large program size due to |Large program size due to |uninitialised global data |uninitialised global data |(SCO) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18713
[Bug libstdc++/18882] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From mikulik at physics dot muni dot cz 2004-12-08 09:01 --- Results of pow(complexlong double, int) calculated by GNU C++ 3.x are wrong. Further, multiplications of complexlong double and int or double are unimplemented: complexlong double x, y; y = 2 * x; y = 2.0 * x; And also complexdouble x, y; y = 2 * x; y = x / 2; Please fix it all. Thanks. -- What|Removed |Added Known to fail||3.3.1 3.4.2 Known to work||2.95 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From nathan at codesourcery dot com 2004-12-08 09:05 --- Subject: Re: [3.4/4.0 regression] template member with same name as class not rejected Mark Mitchell wrote: lerdsuwa at gcc dot gnu dot org wrote: --- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-07 12:34 --- Patch for 3.4 is submitted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00450.html (There is a typo in your test case; you meant nested instead of ested.) That aside, I'm concerned that this fix might cause something else to break, and, given that the problem is only a missed diagnostic, I do not think that's a good tradeoff. Nathan, what do you think? Does this allow templated ctors? If those are still permitted, I think the patch is ok. (IMO it would be simpler to check those things that are allowed to have the same name, rather than all those that aren't. That would not be a sensible 3.4 change though.) nathan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug fortran/18883] New: ICE in gfc_finish_var_decl
Test case from a post on comp.lang.fortran.
$ cat dud.f90
!From: James Van Buskirk [EMAIL PROTECTED]
!Newsgroups: comp.lang.fortran
!Subject: Re: sizeof equivalent in fortran 90 programs
!Message-ID: [EMAIL PROTECTED]
!Organization: Comcast Online
!Date: Wed, 08 Dec 2004 08:00:01 GMT
!
!Rich Townsend [EMAIL PROTECTED] wrote in message
!news:[EMAIL PROTECTED]
!
! Apologies for overlooking your post.
!
!No problem. It just gave me an opportunity to get on my hobby
!horse about initialization expressions. Regarding my hobby
!horse about specification expressions, try using CVF to compile:
!
module helper
implicit none
contains
function dud(x)
integer, intent(in) :: x
character(selected_int_kind(x)+2) dud
dud = repeat('x',len(dud))
end function dud
end module helper
program sik
use helper
implicit none
integer i
integer, parameter :: s(-5:5) = (/(selected_int_kind(i),i=-5,5)/)
do i = -5, 5
write(*,'(4i4)') i,selected_int_kind(i),s(i),len(dud(i))-2
end do
end program sik
!and compare with lf95 or g95.
!
!--
!write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85,
!6.0134700243160014d-154/),(/'x'/)); end
$ gfortran dud.f90
dud.f90: In function 'dud':
dud.f90:20: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:416
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
$ gfortran -v
Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/home/ig25
--enable-languages=c,c++,f95 --disable-shared : (reconfigured) ../gcc/configure
--prefix=/home/ig25 --disable-shared
--with-gcc-version-trigger=/home/ig25/gcc/gcc/version.c
--enable-languages=c,c++,f95 --no-create --no-recursion
Thread model: posix
gcc version 4.0.0 20041206 (experimental)
$
--
Summary: ICE in gfc_finish_var_decl
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18883
Re: complex numbers
Hello Have a look to the implementation: it looks like that even if we switch to the better algorithm, still we don't get fully right C99. Of course this last point must be better investigate (I'm not a floating point expert) but I expect someone replying: let's implement C99 division right instead. Unfortunally I have own no copy of the C99 standard. So I would be glade if you could give me an internet ressource which disscuss the C99 division algorithm or something like that. Then I will try to check what we can do. Meanwhile I think to switch the compiler flag to get the improved algorithmen is a step in the right direction. Yours Andreas Klein
Re: complex numbers
Hello | What was the critice you mentioned above? I can not imagine a sitation in | which I would need the naive implementation. Oh, I got repeated complaints from users that the correct method of computation was slow -- look at the bugzilla archive. I believe there might alos be discussions on GCC main mailing list. It seam that i have trouble to understand how bugzilla works. It would help me if I know the exact bug number. The grammar school algorithms is needed for the primary template because it is the one that gets instantiated, for say, complexint. Notice that such datatypes are required by LIA-3 (in the last phase of development). Yes that right. I was speaking of complexfloting-point types. For complexinteger/rational the grammar school algorithmen is the right one. Yours Andreas Klein
[Bug c++/18884] New: size_t undeclared in namespace std
In file included from /usr/include/c++/3.2.3/bits/stl_algobase.h:69, from /usr/include/c++/3.2.3/bits/stl_tree.h:86, from /usr/include/c++/3.2.3/map:66 /usr/include/c++/3.2.3/new:79: `size_t' undeclared in namespace `std' /usr/include/c++/3.2.3/new:79: declaration of `operator new' as non-function /usr/include/c++/3.2.3/new:79: invalid declarator -- Summary: size_t undeclared in namespace std Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ygs44 at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884
[Bug libmudflap/18885] New: linker does not link libmudflap automatically with -fmudflap
The GCC manual states that libmudflap will be linked if the -fmudflap option is give to the linker: The instrumentation relies on a separate runtime library (libmudflap), which will be linked into a program if -fmudflap is given at link time. But that is not true, the program links only if -lmudflap is also given to the linker. Michael Cieslinski -- Summary: linker does not link libmudflap automatically with - fmudflap Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18885
[Bug c++/16273] [3.3/3.4/4.0 regression] Memory exhausted when using nested classes and virtual functions
--- Additional Comments From david at starks-browning dot com 2004-12-08 10:11 --- What about 3.3? Can it also be fixed there? -- What|Removed |Added CC||david at starks-browning dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16273
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-08 10:12 --- push_class_level_binding is never called for ctors and dtors because of a login in add_method. So my patch doesn't affect template ctor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug libstdc++/18882] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From pcarlini at suse dot de 2004-12-08 10:18 --- So, let's begin from the end: there is nothing *unimplemented* as far as operator* is concerned: have a look to section 26.2.1 of the Standard, there are *no* overloads taking two different template parameters. The first issue, serious, does *not* occur on mainline, and seems a very nasty compiler bug: in fact, the library code for pow(complex, int) is *identical* in mainline and 3.4. Also, there are no specializations for long double vs double and in presence of different behaviors, this is alone a very good reason to suspect the compiler. Gaby, what shall we do? I'm afraid that the compiler people will not be able to work with the full std::complex testcase :-(( but a recategorization seems rather obvious to me. -- What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug c++/18884] size_t undeclared in namespace std
--- Additional Comments From pcarlini at suse dot de 2004-12-08 10:19 --- Please provide a self-contained testcase. Thanks. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884
[Bug libstdc++/17315] Strange compile-time regression in cpp against gcc3.4.1
--- Additional Comments From pcarlini at suse dot de 2004-12-08 10:23 --- Yes, Andrew, we cannot do anything about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17315
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 10:25 --- Subject: Bug 18100 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 10:25:23 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: name-clash4.C Log message: PR c++/18100 * decl.c (lookup_and_check_tag): Diagnose nested class with the same name as enclosing class. * g++.dg/lookup/name-clash4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4520r2=1.4521 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1339r2=1.1340 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4723r2=1.4724 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/name-clash4.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug libstdc++/17315] Strange compile-time regression in cpp against gcc3.4.1
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-08 10:26 --- Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Sure, close it! 4.0.0 is enough faster anyway! :-) Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17315
[Bug libstdc++/17315] Strange compile-time regression in cpp against gcc3.4.1
--- Additional Comments From pcarlini at suse dot de 2004-12-08 10:31 --- Ok ;) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17315
[Bug c++/18886] New: attribute sentinel doesn't work with C++
NULL is expanded as __null in C++.
This is inconsistent with sentinel testing.
There should be one warning for both cases.
gcc version 4.0.0 20041128 (experimental)
$ gcc -Wall -c e.c
e.c: In function 'bar':
e.c:15: warning: missing sentinel in function call
$ g++ -Wall -c e.c
e.c: In function 'void bar()':
e.c:15: warning: missing sentinel in function call
e.c:16: warning: missing sentinel in function call
e,c:
#include stddef.h /* For NULL */
#ifdef __cplusplus
extern C {
#endif
extern int execl (const char *, const char *, ...);
#ifdef __cplusplus
} /* C++ */
#endif
void bar(void)
{
execl (/bin/ls, -aFC);
execl (/bin/ls, -aFC, NULL);
}
--
Summary: attribute sentinel doesn't work with C++
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: salinger at sun dot felk dot cvut dot cz
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i486-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18886
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 10:54 --- Subject: Bug 18100 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-08 10:53:30 Modified files: gcc/cp : ChangeLog name-lookup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: name-clash4.C Log message: PR c++/18100 * name-lookup.c (push_class_level_binding): Diagnose nested class template with the same name as enclosing class. * g++.dg/lookup/name-clash4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.182r2=1.3892.2.183 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.34.2.19r2=1.34.2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.319r2=1.3389.2.320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/name-clash4.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-08 10:56 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug c++/18757] [3.4/4.0 Regression] ICE (on invalid) in get_innermost_template_args
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-08 10:59 --- There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00538.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18757
[Bug c++/18825] [4.0 Regression] ICE segmentation fault in wv2
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-08 11:04 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00543.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18825
bug in /usr/include/c++/3.4/bits/fstream.tcc
error:
/usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
typename std::basic_filebuf_CharT, _Traits::int_type
std::basic_filebuf_CharT, _Traits::underflow()':
/usr/include/c++/3.4/bits/fstream.tcc:277: error: expected
unqualified-id before '(' token
/usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
std::streamsize std::basic_filebuf_CharT, _Traits::xsputn(const
_CharT*, std::streamsize)':
/usr/include/c++/3.4/bits/fstream.tcc:518: error: expected
unqualified-id before '(' token
solution found at:
http://gcc.gnu.org/ml/gcc-bugs/2004-07/msg02128.html
fix:
change line 277 in /usr/include/c++/3.4/bits/fstream.tcc
from: __ilen = std::min(__avail, __buflen);
to: __ilen = min(__avail, __buflen);
and...
change line 518 in /usr/include/c++/3.4/bits/fstream.tcc
from: const streamsize __limit = std::min(__chunk, __bufavail);
to: const streamsize __limit = min(__chunk, __bufavail);
gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
OS:
FreeBSD 5.3-RELEASE
[Bug c++/18886] attribute sentinel doesn't work with C++
--- Additional Comments From joseph at codesourcery dot com 2004-12-08 11:10 --- Subject: Re: New: attribute sentinel doesn't work with C++ On Wed, 8 Dec 2004, salinger at sun dot felk dot cvut dot cz wrote: NULL is expanded as __null in C++. This is inconsistent with sentinel testing. Why do you think it is inconsistent? When NULL is used as a variadic argument, it must be cast to the proper pointer type. This applies in both C and C++, but especially C++ users should expect to have to be much more careful about type-correctness and to include appropriate casts, and C++ requires NULL to be an integer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18886
Re: bug in /usr/include/c++/3.4/bits/fstream.tcc
solution found at: http://gcc.gnu.org/ml/gcc-bugs/2004-07/msg02128.html Solution?!? That PR is closed as INVALID for a reason and in fact nobody actually removed those qualifiers from the library. The user code must be fixed instead. Thanks, Paolo.
[Bug target/11738] ICE could not split insn building libstdc++-v3
--- Additional Comments From pingc at nortelnetworks dot com 2004-12-08
12:18 ---
hi, additional comments
I encountered with a similar issue like this, my gcc version is 2.95.1 19990816.
It is interesting that when I commented some piece of my code, I could
successfully compiling my file, so I just wonder whether is this file too large
(68k),but there are some other files are larger than it.
atmDebug.cc: In function `void atmPmLogDisplay(unsigned int = 0, short unsigned
int = 0, short unsigned int = 0)':
atmDebug.cc:2519: Could not split insn
(insn:TI 520 517 521 (parallel[
(set (reg:CC 71 cr3)
(compare:CC (sign_extend:SI (reg:HI 0 r0))
(const_int 0)))
(clobber (reg:SI 9 r9))
] ) 71 {extendhisi2+2} (insn_list 517 (insn_list 517 (nil)))
(expr_list:REG_DEAD (reg:HI 0 r0)
(expr_list:REG_UNUSED (reg:SI 9 r9)
(nil
../../src/gcc/toplev.c:1472: Internal compiler error in function fatal_insn
Please submit a Problem Report to Cygnus Solutions with send-pr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11738
[Bug c++/18884] size_t undeclared in namespace std
--- Additional Comments From ygs44 at hotmail dot com 2004-12-08 12:51 --- Subject: RE: size_t undeclared in namespace std Just use an empty class but in the header file: #include string From: pcarlini at suse dot de [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug c++/18884] size_t undeclared in namespace std Date: 8 Dec 2004 10:19:56 - --- Additional Comments From pcarlini at suse dot de 2004-12-08 10:19 --- Please provide a self-contained testcase. Thanks. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884
[Bug c++/18884] size_t undeclared in namespace std
--- Additional Comments From pcarlini at suse dot de 2004-12-08 12:56 --- Sorry, cannot reproduce, please double check your installation. Also, 3.2.x is not longer maintained, and of course nothing similar happens with 3.3.x, 3.4.x and current mainline. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884
[Bug c++/18884] size_t undeclared in namespace std
--- Additional Comments From ygs44 at hotmail dot com 2004-12-08 12:59 --- Subject: RE: size_t undeclared in namespace std actually it is the #include sys/time.h From: pcarlini at suse dot de [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug c++/18884] size_t undeclared in namespace std Date: 8 Dec 2004 12:56:33 - --- Additional Comments From pcarlini at suse dot de 2004-12-08 12:56 --- Sorry, cannot reproduce, please double check your installation. Also, 3.2.x is not longer maintained, and of course nothing similar happens with 3.3.x, 3.4.x and current mainline. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884
[Bug c/18887] New: libgcc2.h Improperly determines required built-in function size requirements.
UNITS_PER_WORD is being improperly used as the sole basis for selecting built-in function type sizes in libgcc2.h. As definitions like: #if MIN_UNITS_PER_WORD 1 /* These typedefs are usually forbidden on dsp's with UNITS_PER_WORD 1. */ typedef int SItype __attribute__ ((mode (SI))); typedef unsigned int USItype__attribute__ ((mode (SI))); ... are basically wrong; an appropriate set of default built-in function definitions should be generated for each unique target defined _TYPE_SIZE equal to or larger than the targets's WORD_SIZE (which equals UNITS_PER_WORD * BITS_PER_UNIT). Which isn't what the embedded logic does, it just happens to work for most larg platforms as their UNITS_PER_WORD is large enough not to expose it's faults, as evedenced on 8-bit targets for exampe which would benefit from some word-size (8-bit QI) defaults for mul/div for example, along with built-in definitions for each of it's potentially defined multi-word defined types, which may include 16bit (HI), 32bit(SI), 64bit(DI), 16bit (HF), 32bit(SF), and 64bit(DF) types, which clearly wouldn't be defined by inspection. So suspect that the logic should look more like: #define WORD_SIZE (UNITS_PER_WORD * BITS_PER_UNIT) #if CHAR_TYPE_SIZE == 8 || SHORT_TYPE_SIZE == 8 #define GENERATE_QI_MODE_DEFINITIONS # if WORD_SIZE == 8 #define GENERATE_QI_MODE_BUILTIN_DEFAULTS_BASE # endif #endif #if SHORT_TYPE_SIZE == 16 || INT_TYPE_SIZE == 16 #define GENERATE_HI_MODE_DEFINITIONS # if WORD_SIZE 16 #define GENERATE_HI_MODE_BUILTIN_DEFAULTS_ALL # elif WORD_SIZE == 16 #define GENERATE_HI_MODE_BUILTIN_DEFAULTS_BASE # endif #endif #if INT_TYPE_SIZE == 32 || LONG_TYPE_SIZE == 32 #define GENERATE_SI_MODE_DEFINITIONS # if WORD_SIZE 32 #define GENERATE_SI_MODE_BUILTIN_DEFAULTS_ALL # elif WORD_SIZE == 32 #define GENERATE_SI_MODE_BUILTIN_DEFAULTS_BASE # endif #endif #if LONG_TYPE_SIZE == 64 || LONG_LONG_TYPE_SIZE == 64 #define GENERATE_DI_MODE_DEFINITIONS # if WORD_SIZE 64 #define GENERATE_DI_MODE_BUILTIN_DEFAULTS_ALL # elif WORD_SIZE == 64 #define GENERATE_DI_MODE_BUILTIN_DEFAULTS_BASE # endif #endif #if LONG_LONG_TYPE_SIZE == 128 #define GENERATE_TI_MODE_DEFINITIONS # if WORD_SIZE 128 #define GENERATE_TI_MODE_BUILTIN_DEFAULTS_ALL # elif WORD_SIZE == 128 #define GENERATE_TI_MODE_BUILTIN_DEFAULTS_BASE # endif #endif #if FLOAT_TYPE_SIZE == 16 #define GENERATE_HF_MODE_DEFINITIONS #define GENERATE_HF_MODE_BUILTIN_DEFAULTS_ALL #endif #if FLOAT_TYPE_SIZE == 32 || DOUBLE_TYPE_SIZE == 32 # define GENERATE_SF_MODE_DEFINITIONS # define GENERATE_SF_MODE_BUILTIN_DEFAULTS_ALL #endif #if DOUBLE_TYPE_SIZE == 64 || QUAD_TYPE_SIZE == 64 # define GENERATE_DF_MODE_DEFINITIONS # define GENERATE_DF_MODE_BUILTIN_DEFAULTS_ALL #endif #if QUAD_TYPE_SIZE == 128 # define GENERATE_TF_MODE_DEFINITIONS # define GENERATE_TF_MODE_BUILTIN_DEFAULTS_ALL #endif or somthing like that, thereby all bultins as nessisary are properly defined by default that are larger than the WORD_SIZE, with a few base defaults if equal to the word size for functions typically not implemented in HW such as possiby / and %. -- Summary: libgcc2.h Improperly determines required built-in function size requirements. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schlie at comcast dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: any GCC host triplet: any GCC target triplet: 8/16 bit targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug c++/18884] size_t undeclared in namespace std
--- Additional Comments From pcarlini at suse dot de 2004-12-08 13:11 --- A file only including string or sys/time.h or whatever cannot lead to compilation errors if your system is sane: again, please check it, this is not a gcc bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18884
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 14:08 --- Subject: Bug 18811 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 14:08:28 Modified files: gcc/java : ChangeLog Log message: 2004-12-07 Andrew Haley [EMAIL PROTECTED] PR java/18811: * jcf-parse.c (load_class): Remove sanity test for missing inner class file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1519r2=1.1520 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug libstdc++/18882] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From chris at bubblescope dot net 2004-12-08 14:15
---
Heres a much smaller testcase which shows this bug:
#includestdio.h
class complex
{
public:
complex(long double r=0, long double i=0)
{
__real__ _M_value = r;
__imag__ _M_value = i;
}
long double real() const
{ return __real__ _M_value; }
long double imag() const
{ return __imag__ _M_value; }
__complex__ long double _M_value;
};
int main(void)
{
complex x(2,2),y,z;
int n = 1;
y = (n==1) ? x : complex(3,3);
n=2;
z = (n==1) ? x : complex(3,3);
printf((%Lf,%Lf),(%Lf,%Lf),(%Lf,%Lf)\n,x.real(),x.imag(),y.real(),y.imag(),z.real(),z.imag());
}
This should print (2.0,2.0),(2.0,2.0),(3.0,3.0). Instead it prints
(2.0,2.0),(2.0,0.0),(3.0,3.0).
This bug is fairly obscure: As far as I can see it only appears if:
a) Using long double complex
b) Using n ? y : z operator
c) y is a previously declared variable, z is a temporary created here.
It turns up in bits/cmath.tcc, __cmath_power. A quick hacky fix is to change the
first line of this function from:
_Tp __y = __n % 2 ? __x : 1;
to
_Tp __temp=1;
_Tp __y = __n % 2 ? __x : __temp;
If you want to get your code to work.
I confirm this bug occurs in g++ 3.3.3 (on cygwin), and despite some fiddling I
can't get a similar thing to happen with current CVS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug ada/18816] ACATS c460007 runtime rounding problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:29 --- Fixed by: 2004-12-07 Geert Bosch [EMAIL PROTECTED] * eval_fat.adb: Revert previous change. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18816
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:35 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug c/18887] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:36 --- Is this really a bug as almost all 8/16bit targets provide their own libgcc1? -- What|Removed |Added Status|UNCONFIRMED |WAITING Summary|libgcc2.h Improperly|libgcc2.h Improperly |determines required built-in|determines required built-in |function size requirements. |function size requirements. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug fortran/18826] compiler segfault on assign to array
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 14:38 --- Subject: Bug 18826 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 14:37:59 Modified files: gcc/fortran: ChangeLog Log message: Add missing PR numbers for previous commit: fortran/ PR fortran/18826 * resolve.c (resolve_code): Impose correct restrictions on assigned variable. testsuite/ PR fortran/18826 * gfortran.dg/assign_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.264r2=1.265 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18826
[Bug fortran/18826] compiler segfault on assign to array
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 14:38 --- Subject: Bug 18826 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 14:38:31 Modified files: gcc/testsuite : ChangeLog Log message: Add missing PR numbers for previous commit: fortran/ PR fortran/18826 * resolve.c (resolve_code): Impose correct restrictions on assigned variable. testsuite/ PR fortran/18826 * gfortran.dg/assign_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4726r2=1.4727 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18826
[Bug fortran/18826] compiler segfault on assign to array
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-08 14:39 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18826
[Bug fortran/18870] [g77 regression] Equivalencing two common blocks is not caught
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-08 14:40 --- Confirmed. We don't look through equivalences. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2004-12-08 14:40:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18870
[Bug c++/18886] attribute sentinel doesn't work with C++
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:40 --- Actually the warning is correct __null is the size of an int and the size of the pointer, use a cast, now in C NULL is usually defined as (void*)0 which usually has the cast but you should always cast it anyways. Note this is mainly for 64bit targets. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18886
[Bug fortran/18878] Erronous error message on vaild USE statement
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-08 14:43 --- Confirmed. BTW I tried chaging f=b in the attached program to f=e (invalid, but the error message suggests that we rename the symbol), but this didn't help. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-08 14:43:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18878
[Bug middle-end/18882] [3.3/3.4/4.0? Regression] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:45 --- It works for me on the mainline and 3.3.2 on ppc-darwin, must be a code generation bug then. -- What|Removed |Added Severity|critical|normal Component|libstdc++ |middle-end GCC target triplet||i686-pc-linux-gnu Keywords||wrong-code Summary|wrong results of pow( |[3.3/3.4/4.0? Regression] |complexlong double(2, 1), |wrong results of pow( |odd integer ) |complexlong double(2, 1), ||odd integer ) Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug libfortran/18879] ? not supported in namelist input
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-08 14:47 --- Is this a language extension? Seems likely, as the standard has no concept of stdin and stdout. Could you point to someplace where this extension is specified? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18879
[Bug target/18888] New: [4.0 regression] __builtin_va_arg miscompiled
$ gcc-4.0 -O2 -std=gnu99 vfprintf.i $ ./a.out (null) $ gcc-3.4 -O2 -std=gnu99 vfprintf.i $ ./a.out asdf The problem is that string = (char *) __builtin_va_arg(ap,const char *) is compiled into this: .mmi adds r34 = 8, r34 ;; ld8 r37 = [r34] ie. preincrement instead of postincrement. -- Summary: [4.0 regression] __builtin_va_arg miscompiled Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug c++/18881] c++ multiple inheritance class calls wrong function in threaded environment
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:53 --- Invalid as no compiler knows what branch to take when taking the cast: TestBaseClass_C *self = (TestBaseClass_C *)ptObj; Since ptObj is void*, it is just a normal cast and not a cast which takes a branch of multiple inheritance. Cast when calling pthread_create makes the testcase work: if ((res = pthread_create( thread2_Handle, __null, TestBaseClass_C::StartThread2, (TestBaseClass_C *)this)) != 0 ) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18881
[Bug fortran/18826] compiler segfault on assign to array
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18826
[Bug fortran/18883] ICE in gfc_finish_var_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:54 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-08 14:54:27 date|| Summary| ICE in gfc_finish_var_decl |ICE in gfc_finish_var_decl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18883
[Bug fortran/18883] ICE in gfc_finish_var_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:56 --- Might be related to PR 15164. -- What|Removed |Added BugsThisDependsOn||15164 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18883
[Bug target/18888] [4.0 regression] __builtin_va_arg miscompiled
--- Additional Comments From schwab at suse dot de 2004-12-08 14:56 --- Created an attachment (id=7705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7705action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug target/18888] [4.0 regression] __builtin_va_arg miscompiled
-- What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug middle-end/18882] [3.3/3.4/4.0? Regression] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From pcarlini at suse dot de 2004-12-08 14:59 --- Mainline seems ok on i686/x86_64/ia64-linux. I can confirm that 3.3.3 and 3.4.3 are *not* ok on i686-linux. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail|3.3.1 3.4.2 |3.3.1 3.3.3 3.4.2 3.4.3 Last reconfirmed|-00-00 00:00:00 |2004-12-08 14:59:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug target/18888] [4.0 regression] __builtin_va_arg miscompiled
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 15:06 --- The bug is most likely in ia64_gimplify_va_arg or in std_gimplify_va_arg_expr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
--- Additional Comments From vincent at vinc17 dot org 2004-12-08 15:13 --- I'm wrong. gcc 3.4 (from Debian) still has this problem. So, -ffloat-store is still needed for C compliance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
[Bug ada/18691] 105 acats failure due to ICE in gnat_to_gnu_entity, at ada/decl.c:286
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 15:19 --- Fixed by: 2004-12-07 Richard Kenner [EMAIL PROTECTED] * misc.c (gnat_types_compatible_p, LANG_HOOKS_TYPES_COMPATIBLE_P): Remove. (LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS): New. * adaint.h: (__gnat_dup, __gnat_dup2): Add missing decls. * trans.c (Exception_Handler_to_gnu_sjlj): Also handle renamed exception. (call_to_gnu): Convert to actual DECL_ARG_TYPE, not variant of it. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18691
[Bug c/18887] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From schlie at comcast dot net 2004-12-08 15:24 --- Subject: Re: libgcc2.h Improperly determines required built-in function size requirements. From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED] --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 14:36 --- Is this really a bug as almost all 8/16bit targets provide their own libgcc1? Wouldn't call it critical, but given libgcc2's present selection logic arguably needlessly prevents it's practical use on smaller platforms, I'm sure it's contributed to the decision. (but regardless, would think it would be preferable to remove future impediments to it's use). [I'd be pleased to submit a patch, but would realistically require assistance verifying that the refinements don't create any regressions on existing platforms, would that be potentially acceptable?] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug libmudflap/18885] linker does not link libmudflap automatically with -fmudflap
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 15:32 --- Confirmed, but I don't know it was removed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-08 15:32:50 date|| Summary|linker does not link|linker does not link |libmudflap automatically|libmudflap automatically |with -fmudflap |with -fmudflap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18885
[Bug libstdc++/18889] New: Unable to build libstdc++-v3
After bootstraping the newly built gcc, make fails on linking libstdc++-v3: /usr/src/gcc-3.4.3-objdir/gcc/xgcc -shared-libgcc -B/usr/src/gcc-3.4.3-objdir/ gcc/ -nostdinc++ -L/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/nof/ libstdc++-v3/src -L/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/nof/ libstdc++-v3/src/.libs -B/usr/local/powerpc-unknown-linux-gnu/bin/ -B/usr/local/ powerpc-unknown-linux-gnu/lib/ -isystem /usr/local/powerpc-unknown-linux-gnu/ include -isystem /usr/local/powerpc-unknown-linux-gnu/sys-include -msoft-float -fPIC -mstrict-align -shared /usr/lib/crti.o /usr/src/gcc-3.4.3-objdir/gcc/nof/ crtbeginS.o .libs/allocator.o .libs/codecvt.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o . libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o . libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o . libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o . libs/ext-inst.o .libs/io-inst.o .libs/istream-inst.o .libs/locale-inst.o .libs/ locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o . libs/streambuf-inst.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale- inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/ collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/ monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/ basic_file.o .libs/c++locale.o .libs/libstdc++.lax/libmath.a/stubs.o .libs/ libstdc++.lax/libsupc++convenience.a/del_op.o .libs/libstdc++.lax/ libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/ del_opv.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o .libs/ libstdc++.lax/libsupc++convenience.a/eh_alloc.o .libs/libstdc++.lax/ libsupc++convenience.a/eh_aux_runtime.o .libs/libstdc++.lax/ libsupc++convenience.a/eh_catch.o .libs/libstdc++.lax/libsupc++convenience.a/ eh_exception.o .libs/libstdc++.lax/libsupc++convenience.a/eh_globals.o .libs/ libstdc++.lax/libsupc++convenience.a/eh_personality.o .libs/libstdc++.lax/ libsupc++convenience.a/eh_term_handler.o .libs/libstdc++.lax/ libsupc++convenience.a/eh_terminate.o .libs/libstdc++.lax/libsupc++convenience. a/eh_throw.o .libs/libstdc++.lax/libsupc++convenience.a/eh_type.o .libs/ libstdc++.lax/libsupc++convenience.a/eh_unex_handler.o .libs/libstdc++.lax/ libsupc++convenience.a/guard.o .libs/libstdc++.lax/libsupc++convenience.a/ new_handler.o .libs/libstdc++.lax/libsupc++convenience.a/new_op.o .libs/ libstdc++.lax/libsupc++convenience.a/new_opnt.o .libs/libstdc++.lax/ libsupc++convenience.a/new_opv.o .libs/libstdc++.lax/libsupc++convenience.a/ new_opvnt.o .libs/libstdc++.lax/libsupc++convenience.a/pure.o .libs/libstdc++. lax/libsupc++convenience.a/tinfo.o .libs/libstdc++.lax/libsupc++convenience.a/ tinfo2.o .libs/libstdc++.lax/libsupc++convenience.a/vec.o .libs/libstdc++.lax/ libsupc++convenience.a/vterminate.o .libs/libstdc++.lax/libsupc++convenience.a/ cp-demangle.o -L/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/nof/ libstdc++-v3/src -L/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/nof/ libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/ libsupc++convenience.a -lm -L/usr/src/gcc-3.4.3-objdir/gcc/nof -L/usr/src/gcc-3. 4.3-objdir/gcc -L/usr/local/powerpc-unknown-linux-gnu/bin -L/usr/local/powerpc- unknown-linux-gnu/lib -L/usr/local/lib/gcc/powerpc-unknown-linux-gnu/../../../ powerpc-unknown-linux-gnu/lib -L/usr/local/lib/gcc/powerpc-unknown-linux-gnu/../ .. -lgcc_s_nof -lc -lgcc_s_nof -lm -lgcc_s_nof -lc -lgcc_s_nof /usr/src/gcc-3. 4.3-objdir/gcc/nof/crtsavres.o /usr/src/gcc-3.4.3-objdir/gcc/nof/crtendS.o /usr/ lib/crtn.o -o .libs/libstdc++.so.6.0.3 /usr/lib/crti.o(.init+0x0): In function `_init': : multiple definition of `_init' /usr/lib/crti.o(.init+0x0): first defined here /usr/lib/crti.o(.fini+0x0): In function `_fini': : multiple definition of `_fini' /usr/lib/crti.o(.fini+0x0): first defined here /usr/src/gcc-3.4.3-objdir/gcc/nof/crtbeginS.o(.data.rel+0x0): multiple definition of `__dso_handle' /usr/src/gcc-3.4.3-objdir/gcc/nof/crtbeginS.o(.data.rel+0x0): first defined here /usr/src/gcc-3.4.3-objdir/gcc/nof/crtsavres.o(.text+0x0): In function `_savefpr_14': : multiple definition of `_savefpr_14' [repeat multiple definition errors for _savefpr_14 - 31] [repeat multiple definition errors for _savegpr_14 - 31] [repeat multiple definition errors for _restfpr_14 - 31] [repeat multiple definition errors for _restgpr_14 - 31] [repeat multiple definition errors for _restfpr_14_x - 31] [repeat multiple definition errors for _restgpr_14_x - 31] collect2: ld returned 1 exit status make[7]: *** [libstdc++.la] Error 1 make[7]: Leaving directory `/usr/src/gcc-3.4.3-objdir/powerpc-unknown-linux-gnu/ nof/libstdc++-v3/src' make[6]: *** [all-recursive] Error 1 make[6]:
[Bug libstdc++/18889] Unable to build libstdc++-v3
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 16:20 --- libtool looks like it is messing up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18889
[Bug libfortran/18879] ? not supported in namelist input
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-08 16:24 --- (In reply to comment #1) Is this a language extension? Seems likely, as the standard has no concept of stdin and stdout. Could you point to someplace where this extension is specified? It's in the comments to io.h (line 76 ff): Even more complex, during the execution of a program containing a namelist READ statement, you can specify a question mark character(?) or a question mark character preceded by an equal sign(=?) to get the information of the namelist group. By '?', the name of variables in the namelist will be displayed, by '=?', the name and value of Also, check out http://h18009.www1.hp.com/fortran/docs/lrm/lrm0372.htm . It's specified in green, which I suppose means that it is an extension. Googling for namelist fortran question mark will lead to other examples. Offhand, I can't find a UNIX compiler that doesn't support it. g77 also tries, but the support there is buggy (see PR 18874). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18879
[Bug middle-end/18882] [3.3/3.4 Regression] wrong results of pow( complexlong double(2, 1), odd integer )
--- Additional Comments From mikulik at physics dot muni dot cz 2004-12-08 16:28 --- Further, multiplications of complexlong double and int or double are unimplemented So, let's begin from the end: there is nothing *unimplemented* as far as operator* is concerned: have a look to section 26.2.1 of the Standard, there are *no* overloads taking two different template parameters. Aha, that means that designers of the new Complex class had forgotten that a complex number can be multiplied by an integer -- and thus broke compatibility towards the traditional Complex class :-(( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double
--- Additional Comments From bangerth at dealii dot org 2004-12-08 16:29
---
Here's my shortest version:
---
extern C void abort ();
struct C {
__complex__ long double c;
};
int main() {
C x = {2+2i};
int n = 1;
C y = (n==1) ? x : (C){3+3i};
if (__imag__ y.c != 2)
abort ();
}
--
This fails on 3.3 and 3.4 branches:
g/x /home/bangerth/bin/gcc-3.2*/bin/c++ x.cc ; ./a.out
g/x /home/bangerth/bin/gcc-3.3*/bin/c++ x.cc ; ./a.out
Aborted
g/x /home/bangerth/bin/gcc-3.4*/bin/c++ x.cc ; ./a.out
Aborted
g/x /home/bangerth/bin/gcc-4*/bin/c++ x.cc ; ./a.out
W.
--
What|Removed |Added
Summary|[3.3/3.4 Regression] wrong |[3.3/3.4 Regression] wrong
|results of pow( complexlong|results with complex long
|double(2, 1), odd integer )|double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug libfortran/18653] open call should open for read-only if open for read/write fails.
--- Additional Comments From sje at cup dot hp dot com 2004-12-08 16:52 --- This has been fixed with the patch http://gcc.gnu.org/ml/fortran/2004-12/msg00017.html which is now checked in on ToT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18653
[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-08 16:54 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00599.html Mark, the posted patch is a little different from the one in comment #9. (That's why I didn't apply it yet.) It uses convert_to_integer for the conversion *from* the vector to address your concern about the naming of convert_to_vector. Apart from some additional checks at the beginning the effect should be the same. I have to agree that convert_to_vector misses some sanity checks, but this seems to hold for convert_to_vector as well, since I was able to do the conversion *to* vector with convert_to_integer, too. :-( -- What|Removed |Added AssignedTo|mark at codesourcery dot com|reichelt at gcc dot gnu dot ||org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18073
[Bug libfortran/18653] open call should open for read-only if open for read/write fails.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 16:54 --- Fixed by: 2004-12-07 Steve Ellcey [EMAIL PROTECTED] * io/io.h (open_external): Change prototype. * io/unix.c (regular_file): Change prototype and set flags-action if needed. (open_external): Ditto. * io/open.c (new_unit): Let open_external set flags-action. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18653
[Bug target/18888] [4.0 regression] __builtin_va_arg miscompiled
-- What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From law at redhat dot com 2004-12-08 17:02 --- Subject: Re: DSE is not doing its job for global variables Note that we're only fixing regressions, and I can't see a way to classify this as a regression since the RTL DSE code ought to catch this. This should be marked as postponed until 4.1. This (untested) code ought to do the trick though: --- Additional Comments From law at redhat dot com 2004-12-08 17:02 --- Created an attachment (id=7706) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7706action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug c++/18886] misleading warning from attribute sentinel in C++
--- Additional Comments From salinger at sun dot felk dot cvut dot cz
2004-12-08 17:07 ---
Thanks for explanation.
The warning message was confusing for me.
Could be possible to distinguish between NULL without pointer conversion
and completely forgotten NULL ?
With something like this:
--- gcc/c-common.c.std Wed Dec 8 16:14:12 2004
+++ gcc/c-common.c Wed Dec 8 17:45:03 2004
@@ -5041,7 +5041,12 @@
/* Validate the sentinel. */
if (!POINTER_TYPE_P (TREE_TYPE (TREE_VALUE (sentinel)))
|| !integer_zerop (TREE_VALUE (sentinel)))
- warning (missing sentinel in function call);
+ {
+ if (!integer_zerop (TREE_VALUE (sentinel)))
+ warning (missing sentinel in function call);
+ else
+ warning (wrong sentinel in function call - NULL should be cast
to appropriate pointer type);
+ }
}
}
}
--
What|Removed |Added
Severity|normal |enhancement
Status|RESOLVED|UNCONFIRMED
Keywords||diagnostic
Resolution|INVALID |
Summary|attribute sentinel doesn't |misleading warning from
|work with C++ |attribute sentinel in C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18886
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 17:29 --- Subject: Bug 14853 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-08 17:29:02 Modified files: libjava: ChangeLog Added files: libjava/testsuite/libjava.compile: PR14853.java PR14853.xfail Log message: For PR java/14853: * testsuite/libjava.compile/PR14853.java: New file. * testsuite/libjava.compile/PR14853.xfail: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.2562.2.26r2=1.2562.2.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/PR14853.java.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/PR14853.xfail.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 17:29 --- Subject: Bug 14853 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-08 17:29:42 Modified files: gcc/java : ChangeLog check-init.c java-tree.h parse.y Log message: PR java/14853: * java-tree.h (extract_field_decl): Declare. * parse.y (extract_field_decl): Renamed from strip_out_static_field_access_decl. No longer static. * check-init.c (get_variable_decl): Unwrap COMPOUND_EXPRs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1315.2.19r2=1.1315.2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/check-init.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.53r2=1.53.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.194r2=1.194.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.464.4.2r2=1.464.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug fortran/18890] New: ICE at assign CHARACTER POINTER array to POINTER or ALLOCATABLE one
Example code: $ cat alloc.f90 INTEGER ERR,N PARAMETER (N=10) CHARACTER(LEN=40), POINTER :: vPTR(:) CHARACTER(LEN=40), ALLOCATABLE :: vALLOC(:) ALLOCATE(vPTR(N),STAT=ERR) ALLOCATE(vALLOC(N),STAT=ERR) vALLOC='A' vPTR=vALLOC ! Line cause compiler error WRITE(*,*) vPTR DEALLOCATE(vPTR,STAT=ERR) DEALLOCATE(vALLOC,STAT=ERR) END When compiling it an internal compiler errors arises: $ /usr/local/bin/gfortran/irun/bin/gfortran -static -v --save-temps alloc.f90 Driving: /usr/local/bin/gfortran/irun/bin/gfortran -static -v -save-temps alloc.f90 -lgfortranbegin -lgfortran -lm Reading specs from /usr/local/bin/gfortran/irun/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --enable-languages=c,f95 --prefix=/usr/work/2004343/irun Thread model: posix gcc version 4.0.0 20041208 (experimental) /usr/local/bin/gfortran/irun/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 alloc.f90 -quiet -dumpbase alloc.f90 -mtune=pentiumpro -auxbase alloc -version -o alloc.s GNU F95 version 4.0.0 20041208 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20041202 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 alloc.f90: In function 'MAIN__': alloc.f90:11: internal compiler error: in gfc_trans_scalar_assign, at fortran/trans-expr.c:2005 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. ICE appears with CHARACTER type, REAL or INTEGER seems ok. ICE appears only with POINTER to POINTER or mixed POINTER to/from ALLOCATABLE arrays assigning, ALLOCATABLE to ALLOCATABLE have works. -- Summary: ICE at assign CHARACTER POINTER array to POINTER or ALLOCATABLE one Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: naf at naf dot net dot ru CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18890
[Bug fortran/18891] New: write with no open causes core dump
I believe the attached program is legal, it works with my HP compiler, and the basic premise of the test, write without doing an open, comes from a SPEC test. On ia64-hp-hpux11.20, I get a core dump and putting in the open makes things work. I assume other platforms will show the same behaviour. My debugger croaks on the testcase so I don't know if I can track down the specific problem. Test Case: integer ijk C open(unit=90) write(90,iostat=ierro) ijk end -- Summary: write with no open causes core dump Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ia64-hp-hpux11.20 GCC host triplet: ia64-hp-hpux11.20 GCC target triplet: ia64-hp-hpux11.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 18:03 --- Yes I know it is regression only time which is why I filed it and marked it as an enhancement but I should note that I found this while looking into a benchmark. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-08 18:03:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug fortran/18890] ICE at assign CHARACTER POINTER array to POINTER or ALLOCATABLE one
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 18:06 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-08 18:06:32 date|| Version|tree-ssa|4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18890
[Bug fortran/18891] write with no open causes core dump
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 18:08 --- Hmm, this works for me on ppc-darwin with a compiler built yesterday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 18:09 --- Fixed on the 3.4 branch also. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug java/13607] [meta-bug] access problems in java front-end
-- Bug 13607 depends on bug 14853, which changed state. Bug 14853 Summary: [3.3/3.4 Regression] Assignment to final field permitted when compiling to native http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13607
[Bug fortran/18891] write with no open causes core dump
--- Additional Comments From sje at cup dot hp dot com 2004-12-08 18:47 --- I did some more digging and found that my program was dying in us_write (io/transfer.c) at the line containing '*p = 0;'. I think the problem is one of alignment. p is a pointer to gfc_offset, which is off_t, which is long (at least on IA64) but I do not believe that salloc_w is required to return a pointer to an aligned location. Thus the store of 0 could be to an unaligned location which will cause an abort on ia64-hp-hpux11.20. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug c/17946] wanted: warning for a MASK when a MASK was probably intended
--- Additional Comments From trt at acm dot org 2004-12-08 18:48 --- I should mention there is a hack for the problem noted in comment #5: do the temporary truthvalue conversions with warnings suppressed. That is, change the two instances of tree t = lang_hooks.truthvalue_conversion (default_conversion ($1.value)); to instead be tree t; inhibit_warnings++; t = lang_hooks.truthvalue_conversion (default_conversion ($1.value)); inhibit_warnings--; So, this can be readily made to work after all. But ugh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug libfortran/18891] write with no open causes core dump
-- What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug libfortran/18891] write with no open causes core dump
--- Additional Comments From sje at cup dot hp dot com 2004-12-08 19:06 --- The same problem exists in next_record_w, there there are two statments of the form '*((gfc_offset *) p) = m;' and again there is no gaurentee that p is an aligned address. These must also be fixed for this test case to run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-08 19:13 --- Subject: Bug 17982 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-08 19:13:36 Modified files: gcc: ChangeLog cgraphunit.c tree.h varasm.c gcc/config/h8300: h8300.h Log message: PR 17982 * varasm.c (pending_assemble_externals): New static. (assemble_external_real): Meat of assemble_external split out to this new function. (process_pending_assemble_externals): New function. (assemble_external): Use gcc_assert. If flag_unit_at_a_time is true and the basic test passes, merely cons the decl onto the pending list to be handled later. * tree.h: Declare process_pending_assemble_externals. * cgraphunit.c (cgraph_optimize): Call it. * config/h8300/h8300.h: Do not define ASM_OUTPUT_EXTERNAL. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6750r2=2.6751 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraphunit.c.diff?cvsroot=gccr1=1.90r2=1.91 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.664r2=1.665 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.466r2=1.467 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/h8300/h8300.h.diff?cvsroot=gccr1=1.179r2=1.180 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug rtl-optimization/15135] program hangs in call to sqrt when compiled with -O
--- Additional Comments From gccbug at gammarayburst dot de 2004-12-08 19:39 --- This bug seems to have resurfaced in 3.4.3. It is actually enough to have a negative argument to sqrt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15135
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-08 19:44 --- On i686-pc-mingw32, these three tests hang: ExecutableRun time Memory Usage c94002f.exe 0s 1112KB c974012.exe 0s 1080KB c980001.exe 0s 604KB Andrew Pinski says: I have the same problem with c94002f and c974012 on ppc-darwin These are the following which hang for me on ppc-darwin: c37402a c94002f c94002g c953002 c954020 c954021 c954022 c954023 c954024 c954026 c974012 -- What|Removed |Added Last reconfirmed|2004-11-16 08:29:05 |2004-12-08 19:44:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug ada/17666] Ada tests hanging during make check
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-08 19:44 --- *** This bug has been marked as a duplicate of 18302 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17666
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-12-08 19:44 --- *** Bug 17666 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aaronavay62 at aaronwl dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 20:00 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug c/18632] [4.0 regression]: Can't rename a function after it is used
-- Bug 18632 depends on bug 17982, which changed state. Bug 17982 Summary: [4.0 regression] asm declaration ignored due to conflict with previous rename http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18632
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From law at redhat dot com 2004-12-08 20:02 --- Subject: Re: DSE is not doing its job for global variables On Wed, 2004-12-08 at 18:03 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 18:03 --- Yes I know it is regression only time which is why I filed it and marked it as an enhancement OK. but I should note that I found this while looking into a benchmark. Were you looking at the final output, or just the output from the SSA optimizers? As I mentioned, we have a DSE that works on the RTL level which ought to have a reasonable chance of catching this. If you get a chance to play with the patch and benchmark it, that would be great. Jeff ps. What benchmark? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug tree-optimization/18880] DSE is not doing its job for global variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-08 20:09 --- (In reply to comment #5) Subject: Re: DSE is not doing its job for global variables but I should note that I found this while looking into a benchmark. Were you looking at the final output, or just the output from the SSA optimizers? As I mentioned, we have a DSE that works on the RTL level which ought to have a reasonable chance of catching this. Yes the RTL level one catches it. I just filed it because it would help out on memory usage sometimes. If you get a chance to play with the patch and benchmark it, that would be great. I will try after I after I benchmark my tree combine pass which looks like it could improve even the compile time speed as it removes some ifs which can be proved to be always true. ps. What benchmark? dhrystone 2.0 but it might be a modified version as it was designed to run on DOS and I modified it back to run on UNIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880
[Bug tree-optimization/18892] New: missed SRA of a block copy
The following function:
int f(int a)
{
int i = a -129;
return i == 144;
}
Should be compiled to:
int f1(int a)
{
return (a -129) == 144; // aka return 0;
}
Yes this shows up in real code (gcc), found while testing out my tree combiner.
--
Summary: missed SRA of a block copy
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
BugsThisDependsOn: 15459
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18892
[Bug tree-optimization/15459] [meta-bug] there should be a tree combiner like the rtl one
-- What|Removed |Added OtherBugsDependingO||18892 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15459
