[Bug debug/20998] [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-04-13 18:18:01 |2005-09-09 07:13:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug ada/23788] s-taprop.adb:69:06: warning: cannot depend on "Interrupt_Operations" (wrong categorization)
--- Additional Comments From laurent at guerby dot net 2005-09-09 07:36 --- May be this will work, could you try? *** s-tpinop.ads.~1.9.~ 2005-07-01 08:24:02.0 +0200 --- s-tpinop.ads2005-09-09 09:35:25.0 +0200 *** *** 36,41 --- 36,42 with System.Tasking; package System.Task_Primitives.Interrupt_Operations is +pragma Preelaborate; package IM renames System.Interrupt_Management; package ST renames System.Tasking; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23788
[Bug target/23783] [4.1 Regression] gcc.c-torture/compile/calls.c triggers an ICE
-- What|Removed |Added CC||raj dot khem at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23783
[Bug c++/23793] New: Unhealthy optimization. Accessing double with reinterpret_cast.
This is an error-report. However I will provide some background
for my little piece of code. (The code itself is very simple)
I will try to post on comp.std.c++ in order to make this a part of C++
(maybe c) otherwise I might come back too beck you to implement it just in your
compiler.
There are many reasons. (One and the best is to switch a double based on
intervals) Therefore I would like a VERY FAST FUNCTION to return the sign of a
double (and float and long double) ...
(And compare on a double d<=-0.0 (without branch) wont do the trick. And I can't
blame you because you will have to respect Nan.
Since c/c++ does not have this fast function (skipping Nan)
(which I hope will come) I have no other no other options that to
write it myself (and cheat!)
That means that my trick will only work on doubles in IEEE 754 - with a size of
2.
The sizepart of double (in my case 8 bytes) and int (in my case 4 bytes) could
probably be fixed with the right macros.
However my code will only work on x86 and other machines accepting the IEEE 754
standard. I think Motorola does not follow this - but nevermind.
The code with the bug is : (Read signbit a push it to be one or zero)
int is_not_positive(double v)
{
return ((reinterpret_cast(&v)[1]) >> 31);
}
This works with option O1 (and below)
but fails with O2 (and above)
The O1 correct (but not fast fast code) looks like this:
.file"bug.cpp"
.text
.align 2
.globl _Z15is_not_positived
.type_Z15is_not_positived, @function
_Z15is_not_positived:
.LFB3:
pushl%ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$8, %esp
.LCFI2:
fldl8(%ebp)
fstpl-8(%ebp)
movl-4(%ebp), %eax
shrl$31, %eax
movl%ebp, %esp
popl%ebp
ret
.LFE3:
.size_Z15is_not_positived, .-_Z15is_not_positived
.section.note.GNU-stack,"",@progbits
.ident"GCC: (GNU) 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1,
ssp-3.3.5.20050130-1, pie-8.7.7.1)"
The wrong optimization simply removes:
fldl8(%ebp)
fstpl-8(%ebp)
// I guess that it removes the store.
---
The "wished optimized code" is (notice this is partly manually written so
I might be wrong. I am not an assembler expert)
.LFB4:
pushl%ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
movl12(%ebp), %eax
popl%ebp
shrl$31, %eax
ret
.LFE4:
I am sorry that I have not testet it with a newer version.
(However I am not to bright and last time I did emerge gcc (with accept newest
version I got problems with compiling my kernel))
I hope the answer is "just upgrade you stupid man..."
Regards
Thorbjørn Martsum
PS:
BTW...
I have found a workaround using unsigned long long.
This works with O3 and has only one extra instruction compared to "my best"
movl12(%ebp), %eax
popl%ebp
expands to
movl12(%ebp), %ecx
popl%ebp
movl%ecx, %eax
(a missing peephole-pattern (?) )
But sill WAY WAY Better than what the MS VS6 gives =)
--
Summary: Unhealthy optimization. Accessing double with
reinterpret_cast.
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martsummsw at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23793
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-09 07:53 --- Everything here works. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 21730, which changed state. Bug 21730 Summary: Character length incorrect. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug fortran/18878] [4.0 only] erronous error message on vaild USE statement
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-09 07:55 --- Paul, will your huge module patch be backported to 4.0? -- What|Removed |Added CC||paulthomas2 at wanadoo dot ||fr Summary|Erronous error message on |[4.0 only] erronous error |vaild USE statement |message on vaild USE ||statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18878
[Bug c++/22147] [4.1 regression] ICE in get_bindings
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 08:21 --- I have two patches, one that produces (for the testcase in comment #1) /suse/rguenther/src/tests/pr22147-2.C: In instantiation of A: /suse/rguenther/src/tests/pr22147-2.C:3: instantiated from void foo(A*) [with T = int] /suse/rguenther/src/tests/pr22147-2.C:12: instantiated from here /suse/rguenther/src/tests/pr22147-2.C:7: error: template-id foo for void foo(A*) does not match any template declaration and another one that doesn't complain and accepts the code as valid. So - is this valid code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug fortran/18878] [4.0 only] erronous error message on vaild USE statement
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-09-09 08:21 --- Subject: Re: [4.0 only] erronous error message on vaild USE statement fxcoudert at gcc dot gnu dot org wrote: >--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-09 >07:55 --- >Paul, will your huge module patch be backported to 4.0? > > > I am just in the process of doing it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18878
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-09 08:26 --- Without init_priority, how can you be sure that other libstdc++.so destructors will not be run after __gnu_internal::freelist is destructed? If there are some destructors and they use the mt allocator (whether to allocate some temporary memory or more likely to free some memory), won't it cause big problems? As for the lock being static, mt-allocator.cc is the only user of that lock, so I don't see why it should be externally visible, even if just in libstdc++.a (in libstdc++.so symbol versioning will hide it). If there are other locks used solely in one .cc file, I think they should be made static too. Thanks for writing the testcase. Haven't tried to compile your latest patch yet, do the changes preserve ABI compatibility? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug c++/23793] Unhealthy optimization. Accessing double with reinterpret_cast.
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 08:39 --- All still maintained compilers produce the code you want. I checked 3.4.4, 4.0.0 and current mainline. So FIXED. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||3.4.4 4.0.0 4.1.0 Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23793
[Bug tree-optimization/23282] [4.0 Regression] wrong results at -O on x86
--- Additional Comments From jv244 at cam dot ac dot uk 2005-09-09 08:54 --- > The patch for PR22442 should fix the problem. has anybody updated this patch so far or can it be applied as is ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23282
[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:01 --- Subject: Bug 23624 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-09 09:00:42 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr23624.C Log message: 2005-09-09 Richard Guenther <[EMAIL PROTECTED]> PR c++/23624 * fold-const.c (fold_ternary): Check truth_value_p before calling invert_truthvalue. * g++.dg/tree-ssa/pr23624.C: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9923&r2=2.9924 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.624&r2=1.625 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6039&r2=1.6040 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr23624.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23624
[Bug fortran/18870] [g77 regression] Equivalencing two common blocks is not caught
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:06 --- Subject: Bug 18870 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:06:09 Modified files: gcc/fortran: gfortran.h match.h match.c module.c primary.c trans-common.c trans-decl.c ChangeLog gcc/testsuite/gfortran.dg/g77: 19990905-0.f gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: module_blank_common.f90 module_double_reuse.f90 common_equivalence_1.f common_equivalence_2.f common_equivalence_3.f contained_equivalence_1.f90 module_commons_1.f90 module_equivalence_1.f90 nested_modules_1.f90 Log message: 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * module.c (find_use_name_n): Based on original find_use_name. Either counts number of use names for a given real name or returns use name n. (find_use_name, number_use_names): Interfaces to the function find_use_name_n. (read_module): Add the logic and calls to these functions, so that mutiple reuses of the same real name are loaded. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22304 PR fortran/23270 PR fortran/18870 PR fortran/16511 PR fortran/17917 * gfortran.h: Move definition of BLANK_COMMON_NAME from trans- common.c so that it is accessible to module.c. Add common_head field to gfc_symbol structure. Add field for the equivalence name AND new attr field, in_equivalence. * match.c (gfc_match_common, gfc_match_equivalence): In loops that flag common block equivalences, emit an error if the common blocks are different, using sym->common_head as the common block identifier. Ensure that symbols that are equivalence associated with a common block are marked as being in_common. * module.c (write_blank_common): New. (write_common): Use unmangled common block name. (load_equiv): New function ported from g95. (read_module): Call load_equiv. (write_equiv): New function ported from g95. Correct string referencing for gfc functions. Give module equivalences a unique name. (write_module): Call write_equiv and write_blank_common. * primary.c (match_variable) Old gfc_match_variable, made static and third argument provided to indicate if parent namespace to be visited or not. (gfc_match_variable): New. Interface to match_variable. (gfc_match_equiv_variable): New. Interface to match_variable. * trans-common.c (finish_equivalences): Provide the call to create_common with a gfc_common_header so that module equivalences are made external, rather than local. (find_equivalences): Ensure that all members in common block equivalences are marked as used. This prevents the subsequent call to this function from making local unions. * trans-decl.c (gfc_generate_function_code): Move the call to gfc_generate_contained_functions to after the call to gfc_trans_common so the use-associated, contained common blocks produce the correct references. (gfc_create_module_variable): Return for equivalenced symbols with existing backend declaration. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * gfortran.dg/module_double_reuse.f90: New. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23270 PR fortran/22304 PR fortran/18870 PR fortran/17917 PR fortran/16511 * gfortran.dg/common_equivalence_1.f: New. * gfortran.dg/common_equivalence_2.f: New. * gfortran.dg/common_equivalence_3.f: New. * gfortran.dg/contained_equivalence_1.f90: New. * gfortran.dg/module_blank_common.f90: New. * gfortran.dg/module_commons_1.f90: New. * gfortran.dg/module_equivalence_1.f90: New. * gfortran.dg/nested_modules_1.f90: New. * gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange equivalences and add comment to connect the test with the PR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2 http://gcc.gnu.org/c
[Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:06 --- Subject: Bug 22304 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:06:09 Modified files: gcc/fortran: gfortran.h match.h match.c module.c primary.c trans-common.c trans-decl.c ChangeLog gcc/testsuite/gfortran.dg/g77: 19990905-0.f gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: module_blank_common.f90 module_double_reuse.f90 common_equivalence_1.f common_equivalence_2.f common_equivalence_3.f contained_equivalence_1.f90 module_commons_1.f90 module_equivalence_1.f90 nested_modules_1.f90 Log message: 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * module.c (find_use_name_n): Based on original find_use_name. Either counts number of use names for a given real name or returns use name n. (find_use_name, number_use_names): Interfaces to the function find_use_name_n. (read_module): Add the logic and calls to these functions, so that mutiple reuses of the same real name are loaded. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22304 PR fortran/23270 PR fortran/18870 PR fortran/16511 PR fortran/17917 * gfortran.h: Move definition of BLANK_COMMON_NAME from trans- common.c so that it is accessible to module.c. Add common_head field to gfc_symbol structure. Add field for the equivalence name AND new attr field, in_equivalence. * match.c (gfc_match_common, gfc_match_equivalence): In loops that flag common block equivalences, emit an error if the common blocks are different, using sym->common_head as the common block identifier. Ensure that symbols that are equivalence associated with a common block are marked as being in_common. * module.c (write_blank_common): New. (write_common): Use unmangled common block name. (load_equiv): New function ported from g95. (read_module): Call load_equiv. (write_equiv): New function ported from g95. Correct string referencing for gfc functions. Give module equivalences a unique name. (write_module): Call write_equiv and write_blank_common. * primary.c (match_variable) Old gfc_match_variable, made static and third argument provided to indicate if parent namespace to be visited or not. (gfc_match_variable): New. Interface to match_variable. (gfc_match_equiv_variable): New. Interface to match_variable. * trans-common.c (finish_equivalences): Provide the call to create_common with a gfc_common_header so that module equivalences are made external, rather than local. (find_equivalences): Ensure that all members in common block equivalences are marked as used. This prevents the subsequent call to this function from making local unions. * trans-decl.c (gfc_generate_function_code): Move the call to gfc_generate_contained_functions to after the call to gfc_trans_common so the use-associated, contained common blocks produce the correct references. (gfc_create_module_variable): Return for equivalenced symbols with existing backend declaration. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * gfortran.dg/module_double_reuse.f90: New. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23270 PR fortran/22304 PR fortran/18870 PR fortran/17917 PR fortran/16511 * gfortran.dg/common_equivalence_1.f: New. * gfortran.dg/common_equivalence_2.f: New. * gfortran.dg/common_equivalence_3.f: New. * gfortran.dg/contained_equivalence_1.f90: New. * gfortran.dg/module_blank_common.f90: New. * gfortran.dg/module_commons_1.f90: New. * gfortran.dg/module_equivalence_1.f90: New. * gfortran.dg/nested_modules_1.f90: New. * gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange equivalences and add comment to connect the test with the PR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2 http://gcc.gnu.org/c
[Bug fortran/23270] Undefined reference to module blank common variable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:06 --- Subject: Bug 23270 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:06:09 Modified files: gcc/fortran: gfortran.h match.h match.c module.c primary.c trans-common.c trans-decl.c ChangeLog gcc/testsuite/gfortran.dg/g77: 19990905-0.f gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: module_blank_common.f90 module_double_reuse.f90 common_equivalence_1.f common_equivalence_2.f common_equivalence_3.f contained_equivalence_1.f90 module_commons_1.f90 module_equivalence_1.f90 nested_modules_1.f90 Log message: 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * module.c (find_use_name_n): Based on original find_use_name. Either counts number of use names for a given real name or returns use name n. (find_use_name, number_use_names): Interfaces to the function find_use_name_n. (read_module): Add the logic and calls to these functions, so that mutiple reuses of the same real name are loaded. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22304 PR fortran/23270 PR fortran/18870 PR fortran/16511 PR fortran/17917 * gfortran.h: Move definition of BLANK_COMMON_NAME from trans- common.c so that it is accessible to module.c. Add common_head field to gfc_symbol structure. Add field for the equivalence name AND new attr field, in_equivalence. * match.c (gfc_match_common, gfc_match_equivalence): In loops that flag common block equivalences, emit an error if the common blocks are different, using sym->common_head as the common block identifier. Ensure that symbols that are equivalence associated with a common block are marked as being in_common. * module.c (write_blank_common): New. (write_common): Use unmangled common block name. (load_equiv): New function ported from g95. (read_module): Call load_equiv. (write_equiv): New function ported from g95. Correct string referencing for gfc functions. Give module equivalences a unique name. (write_module): Call write_equiv and write_blank_common. * primary.c (match_variable) Old gfc_match_variable, made static and third argument provided to indicate if parent namespace to be visited or not. (gfc_match_variable): New. Interface to match_variable. (gfc_match_equiv_variable): New. Interface to match_variable. * trans-common.c (finish_equivalences): Provide the call to create_common with a gfc_common_header so that module equivalences are made external, rather than local. (find_equivalences): Ensure that all members in common block equivalences are marked as used. This prevents the subsequent call to this function from making local unions. * trans-decl.c (gfc_generate_function_code): Move the call to gfc_generate_contained_functions to after the call to gfc_trans_common so the use-associated, contained common blocks produce the correct references. (gfc_create_module_variable): Return for equivalenced symbols with existing backend declaration. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * gfortran.dg/module_double_reuse.f90: New. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23270 PR fortran/22304 PR fortran/18870 PR fortran/17917 PR fortran/16511 * gfortran.dg/common_equivalence_1.f: New. * gfortran.dg/common_equivalence_2.f: New. * gfortran.dg/common_equivalence_3.f: New. * gfortran.dg/contained_equivalence_1.f90: New. * gfortran.dg/module_blank_common.f90: New. * gfortran.dg/module_commons_1.f90: New. * gfortran.dg/module_equivalence_1.f90: New. * gfortran.dg/nested_modules_1.f90: New. * gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange equivalences and add comment to connect the test with the PR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2 http://gcc.gnu.org/c
[Bug fortran/18878] [4.0 only] erronous error message on vaild USE statement
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:06 --- Subject: Bug 18878 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:06:09 Modified files: gcc/fortran: gfortran.h match.h match.c module.c primary.c trans-common.c trans-decl.c ChangeLog gcc/testsuite/gfortran.dg/g77: 19990905-0.f gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: module_blank_common.f90 module_double_reuse.f90 common_equivalence_1.f common_equivalence_2.f common_equivalence_3.f contained_equivalence_1.f90 module_commons_1.f90 module_equivalence_1.f90 nested_modules_1.f90 Log message: 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * module.c (find_use_name_n): Based on original find_use_name. Either counts number of use names for a given real name or returns use name n. (find_use_name, number_use_names): Interfaces to the function find_use_name_n. (read_module): Add the logic and calls to these functions, so that mutiple reuses of the same real name are loaded. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22304 PR fortran/23270 PR fortran/18870 PR fortran/16511 PR fortran/17917 * gfortran.h: Move definition of BLANK_COMMON_NAME from trans- common.c so that it is accessible to module.c. Add common_head field to gfc_symbol structure. Add field for the equivalence name AND new attr field, in_equivalence. * match.c (gfc_match_common, gfc_match_equivalence): In loops that flag common block equivalences, emit an error if the common blocks are different, using sym->common_head as the common block identifier. Ensure that symbols that are equivalence associated with a common block are marked as being in_common. * module.c (write_blank_common): New. (write_common): Use unmangled common block name. (load_equiv): New function ported from g95. (read_module): Call load_equiv. (write_equiv): New function ported from g95. Correct string referencing for gfc functions. Give module equivalences a unique name. (write_module): Call write_equiv and write_blank_common. * primary.c (match_variable) Old gfc_match_variable, made static and third argument provided to indicate if parent namespace to be visited or not. (gfc_match_variable): New. Interface to match_variable. (gfc_match_equiv_variable): New. Interface to match_variable. * trans-common.c (finish_equivalences): Provide the call to create_common with a gfc_common_header so that module equivalences are made external, rather than local. (find_equivalences): Ensure that all members in common block equivalences are marked as used. This prevents the subsequent call to this function from making local unions. * trans-decl.c (gfc_generate_function_code): Move the call to gfc_generate_contained_functions to after the call to gfc_trans_common so the use-associated, contained common blocks produce the correct references. (gfc_create_module_variable): Return for equivalenced symbols with existing backend declaration. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * gfortran.dg/module_double_reuse.f90: New. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23270 PR fortran/22304 PR fortran/18870 PR fortran/17917 PR fortran/16511 * gfortran.dg/common_equivalence_1.f: New. * gfortran.dg/common_equivalence_2.f: New. * gfortran.dg/common_equivalence_3.f: New. * gfortran.dg/contained_equivalence_1.f90: New. * gfortran.dg/module_blank_common.f90: New. * gfortran.dg/module_commons_1.f90: New. * gfortran.dg/module_equivalence_1.f90: New. * gfortran.dg/nested_modules_1.f90: New. * gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange equivalences and add comment to connect the test with the PR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2 http://gcc.gnu.org/c
[Bug fortran/16511] Test 19990905-0.f fails with gfortran
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:06 --- Subject: Bug 16511 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:06:09 Modified files: gcc/fortran: gfortran.h match.h match.c module.c primary.c trans-common.c trans-decl.c ChangeLog gcc/testsuite/gfortran.dg/g77: 19990905-0.f gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: module_blank_common.f90 module_double_reuse.f90 common_equivalence_1.f common_equivalence_2.f common_equivalence_3.f contained_equivalence_1.f90 module_commons_1.f90 module_equivalence_1.f90 nested_modules_1.f90 Log message: 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * module.c (find_use_name_n): Based on original find_use_name. Either counts number of use names for a given real name or returns use name n. (find_use_name, number_use_names): Interfaces to the function find_use_name_n. (read_module): Add the logic and calls to these functions, so that mutiple reuses of the same real name are loaded. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22304 PR fortran/23270 PR fortran/18870 PR fortran/16511 PR fortran/17917 * gfortran.h: Move definition of BLANK_COMMON_NAME from trans- common.c so that it is accessible to module.c. Add common_head field to gfc_symbol structure. Add field for the equivalence name AND new attr field, in_equivalence. * match.c (gfc_match_common, gfc_match_equivalence): In loops that flag common block equivalences, emit an error if the common blocks are different, using sym->common_head as the common block identifier. Ensure that symbols that are equivalence associated with a common block are marked as being in_common. * module.c (write_blank_common): New. (write_common): Use unmangled common block name. (load_equiv): New function ported from g95. (read_module): Call load_equiv. (write_equiv): New function ported from g95. Correct string referencing for gfc functions. Give module equivalences a unique name. (write_module): Call write_equiv and write_blank_common. * primary.c (match_variable) Old gfc_match_variable, made static and third argument provided to indicate if parent namespace to be visited or not. (gfc_match_variable): New. Interface to match_variable. (gfc_match_equiv_variable): New. Interface to match_variable. * trans-common.c (finish_equivalences): Provide the call to create_common with a gfc_common_header so that module equivalences are made external, rather than local. (find_equivalences): Ensure that all members in common block equivalences are marked as used. This prevents the subsequent call to this function from making local unions. * trans-decl.c (gfc_generate_function_code): Move the call to gfc_generate_contained_functions to after the call to gfc_trans_common so the use-associated, contained common blocks produce the correct references. (gfc_create_module_variable): Return for equivalenced symbols with existing backend declaration. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * gfortran.dg/module_double_reuse.f90: New. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23270 PR fortran/22304 PR fortran/18870 PR fortran/17917 PR fortran/16511 * gfortran.dg/common_equivalence_1.f: New. * gfortran.dg/common_equivalence_2.f: New. * gfortran.dg/common_equivalence_3.f: New. * gfortran.dg/contained_equivalence_1.f90: New. * gfortran.dg/module_blank_common.f90: New. * gfortran.dg/module_commons_1.f90: New. * gfortran.dg/module_equivalence_1.f90: New. * gfortran.dg/nested_modules_1.f90: New. * gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange equivalences and add comment to connect the test with the PR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2 http://gcc.gnu.org/c
[Bug fortran/17917] gfortran ICE on "equivalence"
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:06 --- Subject: Bug 17917 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:06:09 Modified files: gcc/fortran: gfortran.h match.h match.c module.c primary.c trans-common.c trans-decl.c ChangeLog gcc/testsuite/gfortran.dg/g77: 19990905-0.f gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: module_blank_common.f90 module_double_reuse.f90 common_equivalence_1.f common_equivalence_2.f common_equivalence_3.f contained_equivalence_1.f90 module_commons_1.f90 module_equivalence_1.f90 nested_modules_1.f90 Log message: 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * module.c (find_use_name_n): Based on original find_use_name. Either counts number of use names for a given real name or returns use name n. (find_use_name, number_use_names): Interfaces to the function find_use_name_n. (read_module): Add the logic and calls to these functions, so that mutiple reuses of the same real name are loaded. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22304 PR fortran/23270 PR fortran/18870 PR fortran/16511 PR fortran/17917 * gfortran.h: Move definition of BLANK_COMMON_NAME from trans- common.c so that it is accessible to module.c. Add common_head field to gfc_symbol structure. Add field for the equivalence name AND new attr field, in_equivalence. * match.c (gfc_match_common, gfc_match_equivalence): In loops that flag common block equivalences, emit an error if the common blocks are different, using sym->common_head as the common block identifier. Ensure that symbols that are equivalence associated with a common block are marked as being in_common. * module.c (write_blank_common): New. (write_common): Use unmangled common block name. (load_equiv): New function ported from g95. (read_module): Call load_equiv. (write_equiv): New function ported from g95. Correct string referencing for gfc functions. Give module equivalences a unique name. (write_module): Call write_equiv and write_blank_common. * primary.c (match_variable) Old gfc_match_variable, made static and third argument provided to indicate if parent namespace to be visited or not. (gfc_match_variable): New. Interface to match_variable. (gfc_match_equiv_variable): New. Interface to match_variable. * trans-common.c (finish_equivalences): Provide the call to create_common with a gfc_common_header so that module equivalences are made external, rather than local. (find_equivalences): Ensure that all members in common block equivalences are marked as used. This prevents the subsequent call to this function from making local unions. * trans-decl.c (gfc_generate_function_code): Move the call to gfc_generate_contained_functions to after the call to gfc_trans_common so the use-associated, contained common blocks produce the correct references. (gfc_create_module_variable): Return for equivalenced symbols with existing backend declaration. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18878 * gfortran.dg/module_double_reuse.f90: New. 2005-09-09 Paul Thomas <[EMAIL PROTECTED]> PR fortran/23270 PR fortran/22304 PR fortran/18870 PR fortran/17917 PR fortran/16511 * gfortran.dg/common_equivalence_1.f: New. * gfortran.dg/common_equivalence_2.f: New. * gfortran.dg/common_equivalence_3.f: New. * gfortran.dg/contained_equivalence_1.f90: New. * gfortran.dg/module_blank_common.f90: New. * gfortran.dg/module_commons_1.f90: New. * gfortran.dg/module_equivalence_1.f90: New. * gfortran.dg/nested_modules_1.f90: New. * gfortran.dg/g77/19990905-0.f: Remove XFAIL, rearrange equivalences and add comment to connect the test with the PR. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.58.2.16&r2=1.58.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/match.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.36.1&r2=1.10.36.2 http://gcc.gnu.org/c
[Bug c++/23794] New: C++ frontend passes invalid COND_EXPR to the middle-end
Split out from PR23624.
For
template
void f()
{
int *t, i;
t[i ? 0 : i];
}
the C++ frontend creates i ? 0 : i, i.e. an integer type conditional,
instead of i != 0 ? 0 : i in case of a template only. Causing this is
build_x_conditional_expr
...
expr = build_conditional_expr (ifexp, op1, op2);
if (processing_template_decl && expr != error_mark_node)
return build_min_non_dep (COND_EXPR, expr,
orig_ifexp, orig_op1, orig_op2);
where in the case of a template decl, the valid expr i != 0 ? 0 : i is
thrown away and rebuilt as i ? 0 : i, where the default conversion is no
longer applied. That could be fixed using perform_implicit_conversion
(boolean_type_node, orig_ifexp) - but I don't know if that would succeed
in case of i being a template param. We use this (potentially dependent)
expr later to create a non-dependent expr where we fail to apply the
default conversion, too, in
pt.c:build_non_dependent_expr
we could fix that there, too, performing default conversion if the type
is not correct. And later in
typeck.c:build_array_ref
we happen to call fold on the invalid(?) COND_EXPR.
patch:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01740.html
--
Summary: C++ frontend passes invalid COND_EXPR to the middle-end
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23794
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-09 09:19 --- Hey Jakub. Yeah, I think this can be back-ported. I put in my patch, which looks pretty good on x86/linux. We could proably do something more elaborate to not duplicate some of the symbols but I'm feeling lazy... this is good enough. Sorry about the confusion about the static freelist_mutex. Yes, this was what I was getting at by "linkage clarity" ... I think we are on the same page. Yes, this is a good idea, and I'll clean this up too as a follow-on patch. Umm... so, no, I don't get what you are getting at WRT destructors in libstdc++.so. I think you mean functions in testsuite_shared.so that are asm destrutors but that use __mt_alloc to do allocations or something. You mean, what then? Maybe we'd both be better off if you came up with an example... I think just static ordering in this file will work. Won't that just work? Man, I want that to work. If not, then the init priorty stuff can be re-added. The thing is, there are no config tests for init priority... . I thought support of that was kind of dodgy, non-ELF... if this feature is going to be used, there are other things with __ioinit that can also be done. Anyway. Of more immediate concern is that the testsuite dejagnu hacking is quite weak. For instance, The testsuite file should just be run on linux, so I think that is ok. But the shared object is unconditionally compiled, even for --disable-shared builds also, compiled with a complete hack for flags, likely to only work on linux... It is kind of funny, just to be re-creating an autoconf way of doing this, but doing it in dejagnu. Ugh. Some of this stuff would be easier if we could use Make to build instead of dejagnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug c++/22147] [4.1 regression] ICE in get_bindings
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 09:25 --- At least EDG accepts it in -strict_ansi mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 09:25 --- Subject: Bug 23624 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-09 09:25:25 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr23624.C Log message: 2005-09-09 Richard Guenther <[EMAIL PROTECTED]> PR c++/23624 * fold-const.c (fold): Check truth_value_p before calling invert_truthvalue. * g++.dg/tree-ssa/pr23624.C: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.421&r2=2.7592.2.422 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.517.2.15&r2=1.517.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.395&r2=1.5084.2.396 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr23624.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23624
[Bug c++/22147] [4.1 regression] ICE in get_bindings
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 09:42 --- If this is valid I won't be able to fix this really. Because just adding a forward declaration of class X fixes the problem the "simple fix" Index: cp/pt.c === RCS file: /cvs/gcc/gcc/gcc/cp/pt.c,v retrieving revision 1.1029 diff -c -3 -p -r1.1029 pt.c *** cp/pt.c 5 Sep 2005 16:12:13 - 1.1029 --- cp/pt.c 9 Sep 2005 08:22:06 - *** get_bindings (tree fn, tree decl, tree e *** 10652,10657 --- 10652,10660 /* We can get here for some invalid specializations. */ return NULL_TREE; + if (TREE_CODE (tmpl) == OVERLOAD) + tmpl = OVL_FUNCTION (tmpl); + converted_args = (coerce_template_parms (DECL_INNERMOST_TEMPLATE_PARMS (tmpl), explicit_args, NULL_TREE, is for sure not the right one ;) Backtrace fyi #1 0x08443a42 in tree_contains_struct_check_failed (node=0x8620bc2, en=140643266, file=0x85827f4 "../../../src/gcc-unpatched/gcc/cp/pt.c", line=10656, function=0x858596d "get_bindings") at tree.c:5933 #2 0x080b654f in get_bindings (fn=0x40211b60, decl=0x40236000, explicit_args=0x40233888, check_rettype=1 '\001') at pt.c:10656 #3 0x0807d011 in determine_specialization (template_id=0x40194168, decl=0x40236000, targs_out=0xbfca1f50, need_member_template=0, template_count=1) at pt.c:1430 #4 0x08092640 in tsubst_friend_function (decl=0x40230e80, args=0x40233a38) at pt.c:5106 #5 0x080976ec in instantiate_class_template (type=0x40231c94) at pt.c:5859 #6 0x08102db0 in complete_type (type=0x40231c94) at typeck.c:118 #7 0x0811420b in convert_to_void (expr=0x4020f560, implicit=0x858e62d "statement") at cvt.c:863 #8 0x08129220 in finish_expr_stmt (expr=0x4020f560) at semantics.c:589 ... note that determine_specialization seems to deal with overloads already, so maybe should not call get_bindings here. whatever. NOT looking into this further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug tree-optimization/22444] [4.0/4.1 regression] ICE at tree-into-ssa.c:466
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-09 09:52 --- I think this is memory-related as well. On 2gig RAM, this fails reliably. On 512Mb, no fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
[Bug c++/23793] Unhealthy optimization. Accessing double with reinterpret_cast.
--- Additional Comments From falk at debian dot org 2005-09-09 10:07
---
(In reply to comment #0)
> There are many reasons. (One and the best is to switch a double based on
> intervals) Therefore I would like a VERY FAST FUNCTION to return the sign of a
> double (and float and long double) ...
>
> (And compare on a double d<=-0.0 (without branch) wont do the trick. And I
> can't
> blame you because you will have to respect Nan.
>
> Since c/c++ does not have this fast function (skipping Nan)
> (which I hope will come) I have no other no other options that to
> write it myself (and cheat!)
C99 has this function; it's called signbit. So you should use that.
Newer gcc's also have a __builtin_signbit function.
> The code with the bug is : (Read signbit a push it to be one or zero)
> int is_not_positive(double v)
> {
> return ((reinterpret_cast(&v)[1]) >> 31);
> }
This code has undefined behavior, since it violates aliasing rules.
You should use a union, if you absolutely have to do it this way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23793
[Bug java/20031] [4.0/4.1 regression] ICE on missing files
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-09 10:13 --- One proposal for a patch is here: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00313.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00313.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20031
[Bug c/8960] Segfault with __attribute__ ((mode (...))) in start_function:5702
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 10:17 --- I have verified that (on i686) we neither ICE with an existing nor an unexisting mode with current 3.4, 4.0 and 4.1 compilers. But we reject such decl now with either src/tests/pr8960.c:1: error: mode `SI' applied to inappropriate type or src/tests/pr8960.c:2: error: no data type for mode `TF' I suppose FIXED then, or INVALID. Or whatever. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8960
[Bug c++/9844] Segmentation fault using function with return value with attribute for mode
-- Bug 9844 depends on bug 8960, which changed state. Bug 8960 Summary: Segfault with __attribute__ ((mode (...))) in start_function:5702 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8960 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9844
[Bug target/23783] [4.1 Regression] gcc.c-torture/compile/calls.c triggers an ICE
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-09 10:17 --- Some analysis here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00570.html -- What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-09 10:17:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23783
[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 10:20 --- Fixed everywhere. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.2 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23624
[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 10:21 --- Subject: Bug 23624 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-09 10:20:03 Modified files: gcc: ChangeLog fold-const.c Log message: 2005-09-09 Richard Guenther <[EMAIL PROTECTED]> PR c++/23624 * fold-const.c (fold): Check truth_value_p before calling invert_truthvalue. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.915&r2=2.2326.2.916 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.322.2.18&r2=1.322.2.19 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23624
[Bug c/9860] ICE in emit_move_insn_1, at expr.c:3114
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 10:25 --- As this is not a regression, this is fixed. -- What|Removed |Added Status|NEW |RESOLVED Known to fail||3.4.4 Known to work||4.0.0 4.1.0 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9860
[Bug c/16676] [3.4 Regression] ICE with nested functions and -g1, blocks glibc
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 10:31 --- As this _only_ happens with -O1 -g1 (not -O2 -g1, nor -O1 -g) this is surely not critical (anymore anyways). Re-confirmed on 3.4.4 though. Also this is likely not to be fixed. -- What|Removed |Added Severity|critical|normal Known to fail|3.4.0 |3.4.0 3.4.4 Last reconfirmed|2005-09-04 18:20:27 |2005-09-09 10:31:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16676
[Bug c++/17913] [4.0 Regression] ICE jumping into statement expression
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 10:41 --- This is fixed in the C frontend. C++ needs taking care (4.1 works). By the solution for the C frontend problem I suppose this is now ice-on-invalid-code. -- What|Removed |Added Component|c |c++ Keywords|ice-on-valid-code |ice-on-invalid-code Known to fail||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913
[Bug c/20239] [3.4 Regression] ICE on empty preprocessed input
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 11:57 --- Obvious patch submitted. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00578.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20239
[Bug c/23439] [4.1 regression] "f(){for" crashes the C frontend
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:04 --- Please test and submit the patch(es) or ask for help on doing so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23439
[Bug c/23665] [3.4 Regression] ICE in convert_move with -O3 (ok at -O2)
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09
12:19 ---
Problem of the C frontend using the first decl with int arg
and the inliner expecting to have a double in unit-at-a-time mode, -O1
-funit-at-a-time:
inline double func();
int main(void)
{
double d = func(42);
return 0;
}
inline double func(double arg)
{
return arg * 2.0;
}
src/tests/pr23665.c: In function `main':
src/tests/pr23665.c:10: internal compiler error: in convert_move, at expr.c:563
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
We're probably confusing the two decls. I guess we will not fix this for 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23665
[Bug c++/23793] Unhealthy optimization. Accessing double with reinterpret_cast.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 12:26 --- Reopening to ... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23793
[Bug c++/23793] Unhealthy optimization. Accessing double with reinterpret_cast.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 12:29 --- Mark as a dup of bug 21920 as this is an aliasing violation. Use Falk's suggestion of signbit. It is defined as returning non-zero for negative bit being set. *** This bug has been marked as a duplicate of 21920 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23793
[Bug c/21920] alias violating
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 12:29 --- *** Bug 23793 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||martsummsw at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/8960] Segfault with __attribute__ ((mode (...))) in start_function:5702
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 12:32 --- (In reply to comment #10) > I have verified that (on i686) we neither ICE with an existing nor an > unexisting > mode with current 3.4, 4.0 and 4.1 compilers. This is valid code and should not be rejected. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Target Milestone|3.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8960
[Bug c++/9844] Segmentation fault using function with return value with attribute for mode
-- Bug 9844 depends on bug 8960, which changed state. Bug 8960 Summary: Segfault with __attribute__ ((mode (...))) in start_function:5702 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8960 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9844
[Bug c++/157] Duplicate error message for invalid elaborated type specifier
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:34 --- Was fixed somewhen in 3.4 -- What|Removed |Added Status|NEW |RESOLVED Known to work||3.4.4 Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=157
[Bug c++/772] Statement expressions issues
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:38 --- No testcase? But I think this is fixed on the mainline and only pending on 4.0. See PR17913. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=772
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:42 --- EDG likes this. -- What|Removed |Added Known to fail||3.4.4 4.0.1 4.1.0 Last reconfirmed|2005-09-04 18:18:20 |2005-09-09 12:42:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug c++/2204] G++ doesn't check (member) function parameter for abstract-ness.
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:51 --- Still EDG accepts it, too ;) So, what's with your update Giovanni? If there are no issues left we can close this bug. -- What|Removed |Added Known to fail|2.95.3 3.0.4 3.3.3 3.4.0|2.95.3 3.0.4 3.3.3 3.4.0 ||3.4.4 Known to work||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2204
[Bug c++/2316] g++ fails to overload on language linkage
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:56 --- EDG aggrees with gcc here. Maybe not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/2708] ambiguity check fails for namespace vs class scope
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 12:58 --- Reconfirmed. -- What|Removed |Added Known to fail||4.1.0 Last reconfirmed|2005-09-04 18:20:21 |2005-09-09 12:58:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2708
[Bug c++/2778] -fdump-translation-unit [Simple patch supplied, needs review]
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 13:04 --- As per "The -fdump-translation-unit just doesn't work any more. Only built-in nodes are dumped." -> WONTFIX. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2778
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 13:05 --- Subject: Bug 22084 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-09 13:05:20 Modified files: libjava: ChangeLog libjava/include: i386-signal.h Log message: 2005-09-08 Andrew Haley <[EMAIL PROTECTED]> PR java/22084 * include/i386-signal.h (HANDLE_DIVIDE_OVERFLOW): Bump IP by 1 if R/M field in instruction is 100. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3735&r2=1.3736 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/i386-signal.h.diff?cvsroot=gcc&r1=1.19&r2=1.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug c++/4205] function template can call other function with incorrect parameters
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 13:14 --- EDG accepts this too. -- What|Removed |Added Known to fail||4.1.0 Last reconfirmed|2005-05-01 03:04:25 |2005-09-09 13:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4205
[Bug c/20239] [3.4 Regression] ICE on empty preprocessed input
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-09 13:37 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Known to fail|3.4.0 |3.4.0 3.4.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20239
[Bug c/20239] [3.4 Regression] ICE on empty preprocessed input
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 13:37 --- Subject: Bug 20239 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-09 13:37:07 Modified files: gcc: ChangeLog cppinit.c Log message: 2005-09-09 Richard Guenther <[EMAIL PROTECTED]> PR c/20239 * cppinit.c (cpp_read_main_file): Avoid segfaulting on NULL pfile->map. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.916&r2=2.2326.2.917 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cppinit.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.297.6.6&r2=1.297.6.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20239
[Bug ada/23750] Suggest using a more standard soname for libgnat
--- Additional Comments From ludovic at ludovic-brenta dot org 2005-09-09 13:38 --- Theoretically, the major version number of the soname should change only if there is an ABI change. However, if GNAT changes the ABI with every x.y release it is okay (IMHO) if the soname is libgnat.so.4.1 and not just libgnat.so.4. Also, this "standard" naming is already used by libgcc_s and, I think, libstdc++. -- Ludovic Brenta. -- What|Removed |Added Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23750
[Bug c++/23789] [3.4/4.0/4.1 Regression] compilation error when template parameters have certain complexity
--- Additional Comments From bangerth at dealii dot org 2005-09-09 14:06
---
This is weird indeed. Here's the shortest I can come up with:
---
template struct X {
template
X< (W+(W&&W) > 1 ? W+(W&&W) : 1)+1>
operator + (const X&) const;
};
template void foo()
{
X<6> A,B;
A + B;
}
-
The expression in the return type isn't fully folded, as Andrew noted:
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc
x.cc: In instantiation of ‘X<6>’:
x.cc:10: instantiated from here
x.cc:4: error: ‘(((int)true) + 7)’ is not a valid template argument
for type
‘int’ because it is a non-constant expression
x.cc: In function ‘void foo()’:
x.cc:10: error: no match for ‘operator+‘ in ‘A + B‘
Weird enough, however, is that if I rename operator+ into a regular member
function, then things work just fine. Somebody's gotta explain this to me...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23789
[Bug c++/2316] g++ fails to overload on language linkage
--- Additional Comments From gdr at integrable-solutions dot net 2005-09-09 14:27 --- Subject: Re: g++ fails to overload on language linkage "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | EDG aggrees with gcc here. Maybe not a bug. I don't know why I don't like that syllogism, especially when it is applied to many PRs in row :-/ -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/2778] -fdump-translation-unit [Simple patch supplied, needs review]
--- Additional Comments From gdr at gcc dot gnu dot org 2005-09-09 14:29 --- Undo last change from rguenth. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2778
[Bug c++/2778] -fdump-translation-unit [Simple patch supplied, needs review]
--- Additional Comments From gdr at gcc dot gnu dot org 2005-09-09 14:30 --- . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2778
[Bug fortran/21931] problem with fugly-logint flag and evaluating if statements
-- What|Removed |Added CC||repucul at link dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21931
[Bug fortran/21931] problem with fugly-logint flag and evaluating if statements
--- Additional Comments From bdavis9659 at comcast dot net 2005-09-09 14:38 --- http://gcc.gnu.org/ml/gcc/2005-09/msg00266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21931
[Bug c++/23797] New: ICE (on invalid)
The attached preprocessed file compiled with g++ produces the ICE : include/CGAL/_test_circles_constructions.h: In function 'void _test_circle_construct(CK2)': include/CGAL/_test_circles_constructions.h:294: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I have not found the time to simplify/shorten it, but I believe that there is an invalid use of "typename" in the program. Removing this typename makes the compiler happy. -- Summary: ICE (on invalid) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug c++/23797] ICE (on invalid)
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-09-09 14:41 --- Created an attachment (id=9702) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9702&action=view) gzipped .ii c++ file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug fortran/23677] -fno-automatic does not accept legal save statements
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-09 15:09 --- -fno-automatic should be a synonym for -fmax-stack-var-size=0 instead of what is implemented now. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-09 15:09:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23677
[Bug fortran/23420] ICE on invalid print statement
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-09 15:20 --- Backtrace: (gdb) run pr23420.f90 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/pcl331/schluter/src/gcc/build/gcc/f951 pr23420.f90 Program received signal SIGSEGV, Segmentation fault. 0x0806dfb8 in match_io (k=M_PRINT) at ../../gcc/fortran/io.c:2144 2144 if ((gfc_match_name (name) == MATCH_YES) (gdb) bt #0 0x0806dfb8 in match_io (k=M_PRINT) at ../../gcc/fortran/io.c:2144 #1 0x0806e1be in gfc_match_print () at ../../gcc/fortran/io.c:2342 #2 0x0807b23a in match_word (str=Variable "str" is not available. ) at ../../gcc/fortran/parse.c:65 #3 0x0807b4b9 in decode_statement () at ../../gcc/fortran/parse.c:251 #4 0x0807bd85 in next_statement () at ../../gcc/fortran/parse.c:356 #5 0x0807c895 in parse_spec (st=ST_NONE) at ../../gcc/fortran/parse.c:1530 #6 0x0807d6f9 in parse_progunit (st=ST_ARITHMETIC_IF) at ../../gcc/fortran/parse.c:2295 #7 0x0807d9e4 in gfc_parse_file () at ../../gcc/fortran/parse.c:2581 #8 0x08097455 in gfc_be_parse_file (set_yydebug=0) at ../../gcc/fortran/f95-lang.c:256 #9 0x0836b89a in toplev_main (argc=2, argv=0xb9d4) at ../../gcc/toplev.c:971 #10 0x40065db6 in __libc_start_main () from /lib/libc.so.6 #11 0x0804ab91 in _start () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23420
[Bug fortran/19242] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1106
--- Additional Comments From zeekec at mad dot scientist dot com 2005-09-09 15:21 --- Indeed, PR15326, seems to have fixed this. Changing to fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19242
[Bug fortran/23114] [4.0 only] Bad interaction between character, dimension and interface
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-09 15:27 --- This bug was fixed between 20050908 and 20050909 on mainline. Don't know about 4.0, however: too many patches commited in 24 hours! ;-) -- What|Removed |Added Summary|Bad interaction between |[4.0 only] Bad interaction |character, dimension and|between character, dimension |interface |and interface http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23114
[Bug fortran/23420] ICE on invalid print statement
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-09 15:32 --- Working on a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-08-16 12:12:30 |2005-09-09 15:32:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23420
[Bug c++/772] Statement expressions issues
--- Additional Comments From joseph at codesourcery dot com 2005-09-09 15:41 --- Subject: Re: Statement expressions issues On Fri, 9 Sep 2005, rguenth at gcc dot gnu dot org wrote: > No testcase? But I think this is fixed on the mainline and only pending on > 4.0. > See PR17913. The test is gcc.dg/stmt-expr-label-*.c (modulo the exact diagnostic text) and I don't think this is fixed for C++ on mainline. This is separate from bug 17913 where there is a case which is valid at compile time and invalid at runtime, involving computed gotos: gcc.c-torture/compile/pr17913.c, which formerly ICEd with optimization but was fixed not to do so (at least for C; appears fixed for C++ as well with the mainline/4.0 compilers I have to hand to test but they are rather old). It just happens that almost all cases of bug 17913 were addressed for C by fixing bug 772 for C, leaving only the case of computed gotos to be fixed separately in 17913 (for C). The rules for invalidity for jumps into statement expressions are much the same as those in C++ for jumps bypassing initializations (imagining that each statement expression starts with such an initialization); it might be possible to reuse that code to fix this bug for C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=772
[Bug c++/2778] -fdump-translation-unit [Simple patch supplied, needs review]
--- Additional Comments From gdr at gcc dot gnu dot org 2005-09-09 15:56 --- . -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2003-11-16 00:25:17 |2005-09-09 15:56:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2778
[Bug fortran/23420] ICE on invalid print statement
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-09 15:58
---
This patch fixes the problem in match_io.c, but leaves us with a preexisting
deficiency in I/O statement parsing:
PRINT I+I
END
will now segfault in trans-io.c.
Index: io.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/io.c,v
retrieving revision 1.31
diff -c -3 -p -r1.31 io.c
*** io.c4 Sep 2005 12:08:40 - 1.31
--- io.c9 Sep 2005 15:38:07 -
*** match_io (io_kind k)
*** 2133,2169
if (gfc_match_char ('(') == MATCH_NO)
{
if (k == M_WRITE)
goto syntax;
! else if (k == M_PRINT
! && (gfc_current_form == FORM_FIXED
! || gfc_peek_char () == ' '))
{
/* Treat the non-standard case of PRINT namelist. */
! where = gfc_current_locus;
! if ((gfc_match_name (name) == MATCH_YES)
! && !gfc_find_symbol (name, NULL, 1, &sym)
! && sym->attr.flavor == FL_NAMELIST)
{
! if (gfc_notify_std (GFC_STD_GNU, "PRINT namelist at "
! "%C is an extension") == FAILURE)
{
! m = MATCH_ERROR;
! goto cleanup;
}
! if (gfc_match_eos () == MATCH_NO)
! {
! gfc_error ("Namelist followed by I/O list at %C");
! m = MATCH_ERROR;
! goto cleanup;
! }
!
! dt->io_unit = default_unit (k);
! dt->namelist = sym;
! goto get_io_list;
}
- else
- gfc_current_locus = where;
}
if (gfc_current_form == FORM_FREE)
--- 2133,2170
if (gfc_match_char ('(') == MATCH_NO)
{
+ where = gfc_current_locus
if (k == M_WRITE)
goto syntax;
! else if (k == M_PRINT)
{
/* Treat the non-standard case of PRINT namelist. */
! if ((gfc_current_form == FORM_FIXED || gfc_peek_char () == ' ')
! && gfc_match_name (name) == MATCH_YES)
{
! gfc_find_symbol (name, NULL, 1, &sym);
! if (sym && sym->attr.flavor == FL_NAMELIST)
{
! if (gfc_notify_std (GFC_STD_GNU, "PRINT namelist at "
! "%C is an extension") == FAILURE)
! {
! m = MATCH_ERROR;
! goto cleanup;
! }
! if (gfc_match_eos () == MATCH_NO)
! {
! gfc_error ("Namelist followed by I/O list at %C");
! m = MATCH_ERROR;
! goto cleanup;
! }
!
! dt->io_unit = default_unit (k);
! dt->namelist = sym;
! goto get_io_list;
}
! else
! gfc_current_locus = where;
}
}
if (gfc_current_form == FORM_FREE)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23420
[Bug libfortran/23784] close doesn't reset ioparm on error exit
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-09
16:00 ---
It's just that we should call library_end() before returning in st_close:
Index: libgfortran/io/close.c
===
RCS file: /cvs/gcc/gcc/libgfortran/io/close.c,v
retrieving revision 1.8
diff -p -u -r1.8 close.c
--- libgfortran/io/close.c 27 Aug 2005 16:01:54 - 1.8
+++ libgfortran/io/close.c 9 Sep 2005 15:59:16 -
@@ -64,7 +64,10 @@ st_close (void)
"Bad STATUS parameter in CLOSE statement");
if (ioparm.library_return != LIBRARY_OK)
+ {
+library_end ();
return;
+ }
u = find_unit (ioparm.unit);
if (u != NULL)
No time to regtest this, but if someone want to test & commit as obvious, he can
gladly take credit for this genial patch :)
--
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||patch
Last reconfirmed|-00-00 00:00:00 |2005-09-09 16:00:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23784
[Bug fortran/23420] ICE on invalid print statement
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-09 16:01 --- The new segfault's here: (gdb) run pr23420.f90 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/pcl331/schluter/src/gcc/build/gcc/f951 pr23420.f90 MAIN__ Program received signal SIGSEGV, Segmentation fault. 0x080b56a7 in set_string (block=0xbfffda24, postblock=0xbfffda1c, var=Variable "var" is not available. ) at ../../gcc/fortran/trans-io.c:456 456 if (e->ts.type == BT_INTEGER && e->symtree->n.sym->attr.assign == 1) (gdb) bt #0 0x080b56a7 in set_string (block=0xbfffda24, postblock=0xbfffda1c, var=Variable "var" is not available. ) at ../../gcc/fortran/trans-io.c:456 #1 0x080b6343 in build_dt (function=0x85d6078, code=0x868d2f0) at ../../gcc/fortran/trans-io.c:1170 #2 0x080987da in gfc_trans_code (code=0x868d2f0) at ../../gcc/fortran/trans.c:593 #3 0x080a82ae in gfc_generate_function_code (ns=0x868cd08) at ../../gcc/fortran/trans-decl.c:2415 #4 0x08097e54 in gfc_generate_code (ns=0x868cd08) at ../../gcc/fortran/trans.c:683 #5 0x0807df21 in gfc_parse_file () at ../../gcc/fortran/parse.c:2642 #6 0x08097815 in gfc_be_parse_file (set_yydebug=0) at ../../gcc/fortran/f95-lang.c:256 #7 0x0836c275 in toplev_main (argc=2, argv=0xbfffdc44) at ../../gcc/toplev.c:990 #8 0x40065db6 in __libc_start_main () from /lib/libc.so.6 #9 0x0804ab91 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23420
[Bug libgcj/23182] instanceof sometimes fails if compiled with -findirect-dispatch
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 16:04 --- Subject: Bug 23182 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-09 16:04:13 Modified files: gcc/java : ChangeLog expr.c Log message: 2005-09-09 Andrew Haley <[EMAIL PROTECTED]> PR libgcj/23182 * expr.c (pop_type_0): If the expected type is object or ptr (i.e. void*), return the type of the object we just popped from the stack. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1662&r2=1.1663 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.236&r2=1.237 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23182
[Bug tree-optimization/23509] [4.1 regression] ICE with ivopts
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 16:17 --- Subject: Bug 23509 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-09 16:17:26 Modified files: gcc: ChangeLog tree-cfg.c tree-ssa-loop-ivopts.c Log message: PR tree-optimization/23509 * tree-cfg.c (replace_uses_by): Use replace_exp. * tree-ssa-loop-ivopts.c (get_ref_tag): Assert that dereferenced pointers have name_mem_tag or type_mem_tag set. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9927&r2=2.9928 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.219&r2=2.220 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.87&r2=2.88 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23509
[Bug fortran/23798] New: gfortran hangs while parsing subroutine
It appears that the latest version (and older versions) of gfortran hang while compiling the attached fortran code. It looks like it is related to the character strings being dimensioned by a length parameter passed in the arguments of the subroutine. If I hard code the length to a constant, the parser works fine. -- Summary: gfortran hangs while parsing subroutine Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rrr6399 at futuretek dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23798
[Bug fortran/23798] gfortran hangs while parsing subroutine
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-09 16:20 --- Created an attachment (id=9703) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9703&action=view) subroutine that causes gfortran -c to hang during parsing uncomment the 10th line and comment the 9th line to compile the code successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23798
[Bug c++/23797] ICE (on invalid)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 16:24 --- reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug c++/23797] [3.4/4.0/4.1 Regression] ICE (on invalid)
-- What|Removed |Added Keywords||ice-on-invalid-code Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Summary|ICE (on invalid)|[3.4/4.0/4.1 Regression] ICE ||(on invalid) Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-09 16:33 --- Fixed in 4.1. -- What|Removed |Added Summary|[4.0/4.1 Regression] pragma |[4.0 Regression] pragma |interface/implementation|interface/implementation |still break synthesized |still break synthesized |methods |methods http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug c++/23708] [4.0 Regression] Non-inline function incorrectly treated as inline when using precompiled headers
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-09 16:38 --- Fixed in 4.1 by the patch for 22252. This isn't quite a "duplicate" bug so I'm leaving the bug open; it's conceivable that we'd fix this bug, without fixing 22252, for 4.0.x. -- What|Removed |Added Summary|[4.0/4.1 Regression] Non- |[4.0 Regression] Non-inline |inline function incorrectly |function incorrectly treated |treated as inline when using|as inline when using |precompiled headers |precompiled headers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23708
[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-09 16:52 --- The reduced testcase in comment #5 starts failing with this patch from rakdver: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00814.html -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-09 16:57 --- The testcase starts failing with this patch from zadeck and dberlin: http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00635.html -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug c++/23789] [3.4/4.0/4.1 Regression] compilation error when template parameters have certain complexity
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-09 16:58 --- The problem here is that the NOP_EXPR case in tsubst is implemented by build_nop, which unconditionally adds a NOP_EXPR. We need to simplify the NOP_EXPR away so that fold can do its job. Perhaps we should have a CAST_EXPR here, rather than a NOP_EXPR. I'll work it out. -- 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=23789
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 17:00 --- (In reply to comment #5) > The testcase starts failing with this patch from zadeck and dberlin: It was decided this was really a latent front-end bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-09 17:00 --- It's a latent FE bug, hopefully one that an FE person can solve. It's out of my FE experience league, unfortunately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug c++/23357] [4.1 Regression] ICE with __alignof__ on template arguments
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-09 17:01 --- The testcase starts failing with this patch from pinskia: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00068.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23357
[Bug c++/23357] [4.1 Regression] ICE with __alignof__ on template arguments
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 17:11 --- This is more of the issue for a front-end person, mainly why are we calling convert_to_integer while in a template since that assumes all the types are set up correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23357
[Bug target/23775] [4.1 Regression] wrong code in argument passing
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-09 17:43 --- The difference between 4.0 and HEAD is the expr.c hunk of http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html If Paolo's reversion of that: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00589.html makes it in, the testcase will pass again. The real problem is I think that when calls.c decides to save stack area under an argument for the inner expand_call, but that argument partially overlaps with the result of the call, we save/restore the argument with the inner expand_call's argument mode and don't just limit to the actual bytes that have already been initialized. So we read some uninitialized bits from the stack and overwrite with them the computed argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug tree-optimization/23509] [4.1 regression] ICE with ivopts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 17:59 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23509
[Bug c++/23799] New: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
Executing on host: /tmp/cvs/gcc-20050909/Build/gcc/testsuite/../g++ -B/tmp/cvs/gcc-20050909/Build/gcc/testsuite/../ /tmp/cvs/gcc-20050909/gcc/testsuite/g++.dg/init/pr23180-2.C -nostdinc++ -I/tmp/cvs/gcc-20050909/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -I/tmp/cvs/gcc-20050909/Build/ia64-suse-linux/libstdc++-v3/include -I/tmp/cvs/gcc-20050909/libstdc++-v3/libsupc++ -I/tmp/cvs/gcc-20050909/libstdc++-v3/include/backward -I/tmp/cvs/gcc-20050909/libstdc++-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o pr23180-2.s(timeout = 300) /tmp/cvs/gcc-20050909/gcc/testsuite/g++.dg/init/pr23180-2.C:10: internal compiler error: no-op convert from 8 to 4 bytes in initializer -- Summary: [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: c++ 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-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug debug/20998] [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From dpatel at apple dot com 2005-09-09 18:01 --- Subject: Re: [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions It does not fix gdb.cp/anon-union.exp (from GDB testsuite) failures using darwin GDB. If you do not get any other feedback/info then I'll try to get back to this next week. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-09 18:05 --- Note this is a new testcase for 4.1. Just to double check, did you try compiling it with 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-09 18:21 --- Well, maybe we will need init priority. I'm still thinking about that part. Adding it is simple enough if we need it. However, I'd like to check this in just to see what happens with the rest of it. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libgcj/23288] java.lang.Class's #getPackage() returns null
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-09
18:35 ---
Note also that Package.getVersion fails when the class file comes from a
jar. With the included example you can see this by making a manifest file
(in my example named "J/Man"):
Main-Class: men.gcjpackage.TestPackage
Name: men/gcjpackage/
Specification-Title: JChemPaint
Specification-Version: 2.0
Specification-Vendor: The JChemPaint Project
Implementation-Title: jchempaint
Implementation-Version: 2.0.12
Implementation-Vendor: The JChemPaint Project
Then make a jar:
jar -cv -m J/Man -f J/men.jar men/gcjpackage/*.class
And change the test to:
package men.gcjpackage;
public class TestPackage
{
public static void main(String[] args)
{
System.out.println("ClassLoader: " + TestPackage.class.getClassLoader() );
Package x = TestPackage.class.getPackage();
System.out.println("Package: " + x);
System.out.println("Version: " + x.getImplementationVersion());
} // main
} // TestPackage
With the JDK the last line prints:
Version: 2.0.12
With gij it prints:
Version: null
As the names suggest, this prevents JChemPaint from working:
http://almost.cubic.uni-koeln.de/cdk/jcp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23288
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
--- Additional Comments From schwab at suse dot de 2005-09-09 18:51 --- Sure I did. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-09 18:56 --- Subject: Bug 22252 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-09 18:56:16 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog decl.c decl2.c pt.c semantics.c Added files: gcc/testsuite/g++.dg/ext: interface1.C interface1.h interface1a.cc Log message: PR c++/22252 * decl.c (start_preparsed_function): Do not pay attention to #pragma interface for implicitly-defined methods. * decl2.c (cp_finish_file): Do not complain about uses of inline functions that have bodies, even if we decided not to emit the body in this translation unit. * semantics.c (note_decl_for_pch): Do not mess with linkage. (expand_or_defer_fn): Make inline, non-template functions COMDAT at this point. PR c++/22252 * g++.dg/ext/interface1.C: New test. * g++.dg/ext/interface1.h: Likewise. * g++.dg/ext/interface1a.cc: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6041&r2=1.6042 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4880&r2=1.4881 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1424&r2=1.1425 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.799&r2=1.800 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1029&r2=1.1030 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.487&r2=1.488 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/interface1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/interface1.h.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/interface1a.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug debug/20998] [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-09 19:08 --- Well it does with cvs head gdb on linux, both stabs and dwarf2. If you'll verify that you see something akin to .stabs "z:(0,7)",128,0,0,-4 .stabs "w:(0,9)",128,0,0,-4 in your assembly file, I'll close this as fixed on the gcc side. -- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-09 19:14 --- The reduced testcase from comment #3 starts failing with this patch from zadeck and dberlin: http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00635.html -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
