[Bug fortran/29431] Not Implemented: complex character array constructors
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-13 07:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29431
[Bug libfortran/26540] [4.1 only] intrinsics/signal.c warnings
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-13 07:22 --- Since it's only a build-time warning, I won't backport that patch to 4.1 and I close the PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug middle-end/29440] 4.2 20061007 experimental misscompiles libavcodec/h264.o
--- Comment #7 from poirierg at gmail dot com 2006-10-13 07:37 --- (In reply to comment #3) > Does it work when compiled with -O0 instead of -O4? How about -O1? > > Besies above, I noticed that the asm in get_cabac looks to be clobbering > memory > but is not marked as such. Damn, that was the bug. I don't quite understand why 4.0 and 4.1 weren't affected on Linux, whereas 3.4.6 was affected. Sorry for the trouble, and thanks for the great work! Guillaume -- poirierg at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-13 07:38
---
(In reply to comment #3)
> Can you upgrade and confirm that the code compiles?
No, Steve, it doesn't work for me either on i686-linux. I downloaded the code
from comment #2 (and to answer Paul: it doesn't contain any tab), and it fails
to compile with
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061012
--enable-languages=c,fortran
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.2.0 20061012 (experimental)
$ gfortran -c ircmva.f
In file ircmva.f:91
END
1
Internal Error at (1):
gfc_resolve_expr(): Bad expression type
while the same file compiles fine on x86_64-unknown-linux-gnu. The backtrace of
the ICE is:
Breakpoint 2, gfc_internal_error (
format=0x85d2f48 "gfc_resolve_expr(): Bad expression type")
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c:667
667 /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c: No such
file or directory.
in /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c
(gdb) where
#0 gfc_internal_error (
format=0x85d2f48 "gfc_resolve_expr(): Bad expression type")
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c:667
#1 0x0808e082 in gfc_resolve_expr (e=0x9407790)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:3107
#2 0x0809162b in resolve_code (code=0x9407588, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4864
#3 0x08093edd in gfc_resolve_blocks (b=0x9407548, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4796
#4 0x080915fa in resolve_code (code=0x9407678, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4853
#5 0x08093edd in gfc_resolve_blocks (b=0x94062f8, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4796
#6 0x080915fa in resolve_code (code=0x9404c68, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4853
#7 0x08092e83 in gfc_resolve (ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:6919
#8 0x08087d39 in gfc_parse_file ()
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/parse.c:3212
#9 0x080a928d in gfc_be_parse_file (set_yydebug=0)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/f95-lang.c:303
#10 0x083a6dc5 in toplev_main (argc=14, argv=0xbfc6ba64)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/toplev.c:1033
#11 0x080de53f in main (argc=2, argv=0x0)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/main.c:35
gfc_internal_error is called in resolve.c because, in gfc_resolve_expr,
argument e has value:
(gdb) p *e
$2 = {expr_type = 0, ts = {type = BT_INTEGER, kind = 4, derived = 0x0,
cl = 0x0}, rank = 0, shape = 0x0, symtree = 0x96ae868, ref = 0x96d77e8,
where = {nextc = 0x96cc62b "NUMCMP(NRCMP)", ' ' ,
lb = 0x96cc608}, from_H = 0, inline_noncopying_intrinsic = 0, value = {
logical = 0, integer = {{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}},
real = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}},
complex = {r = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0}}}, op = {
operator = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0},
function = {actual = 0x0, name = 0x0, isym = 0x0, esym = 0x0},
character = {length = 0, string = 0x0}, constructor = 0x0}}
It has expr_type = 0, which should not happen. This happens for symbol numcmp:
(gdb) p *e->symtree
$3 = {priority = 15818, left = 0x0, right = 0x0, name = 0x96d07cd "numcmp",
ambiguous = 0, n = {sym = 0x96d20b8, uop = 0x96d20b8, common = 0x96d20b8}}
(gdb) p *e->symtree->n.sym
$4 = {name = 0x96d07cd "numcmp", module = 0x0, declared_at = {
nextc = 0x96b1f20 ", NCMPVE, NCMPRF,", ' ' ,
lb = 0x96b1ef0}, ts = {type = BT_INTEGER, kind = 4, derived = 0x0,
cl = 0x0}, attr = {allocatable = 0, dimension = 1, external = 0,
intrinsic = 0, optional = 0, pointer = 0, save = 0, target = 0, dummy = 1,
result = 0, assign = 0, threadprivate = 0, data = 0, use_assoc = 0,
in_namelist = 0, in_common = 0, in_equivalence = 0, function = 0,
subroutine = 0, generic = 0, implicit_type = 0, untyped = 0, sequence = 0,
elemental = 0, pure = 0, recursive = 0, unmaskable = 0, masked = 0,
contained = 0, noreturn = 0, entry = 0, entry_master = 0,
mixed_entry_master = 0, always_explicit = 0, referenced = 1,
is_main_program = 0, access = ACCESS_UNKNOWN, intent = INTENT_UNKNOWN,
[Bug c/28419] [4.1/4.2 regression] ICE using __FUNCTION__ in invalid code
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-10-13 07:42 --- Subject: Bug 28419 Author: hubicka Date: Fri Oct 13 07:41:53 2006 New Revision: 117684 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117684 Log: PR c/28419 * c-decl.c (c_make_fname_decl): Do not segfault in case where current_function_decl is set but current_function_scope is not. * gcc.dg/pr28319.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr28419.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28419
[Bug c/28419] [4.1 regression] ICE using __FUNCTION__ in invalid code
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-10-13 07:42 --- Fixed in mainline. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.1 regression] ICE using |using __FUNCTION__ in |__FUNCTION__ in invalid code |invalid code| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28419
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-13 07:54 --- I managed to trim it down to: implicit none integer :: n, i character(len=16),parameter :: s = "" if (s(9:16) == "90123456") then endif if (i > 0) then write (i,*) n call foo(0) endif do i = 1, n end do end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug debug/29443] [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #3 from tbm at cyrius dot com 2006-10-13 08:05 --- (In reply to comment #2) > This works on 4.1.2 20061007 on i686-linux-gnu. Fails for me with gcc 4.1.2 20061011 on x86_64-unknown-linux-gnu. From the Debian build logs it seems the ICE only appeared on x86_64. -- tbm at cyrius dot com changed: What|Removed |Added GCC target triplet||x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug fortran/21435] fails to open nonexisting file with status scratch
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-13 08:19 --- Subject: Bug 21435 Author: fxcoudert Date: Fri Oct 13 08:18:50 2006 New Revision: 117685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117685 Log: PR fortran/21435 * io.c (compare_to_allowed_values): New function. (gfc_match_open): Add checks for constant values of specifiers. (gfc_match_close): Add checks for constant values of the STATUS specifier. * gcc/testsuite/gfortran.dg/io_constraints_3.f90: New test. * gcc/testsuite/gfortran.dg/open_access_append_1.f90: Add checks for compile-time warnings. * gcc/testsuite/gfortran.dg/pr20163-2.f: Likewise. * gcc/testsuite/gfortran.dg/iostat_2.f90: Likewise. * gcc/testsuite/gfortran.dg/label_4.f90: Delete the temporary file. * gcc/testsuite/gfortran.dg/direct_io_2.f90: Add a FILE= specifier. * gcc/testsuite/gfortran.dg/iomsg_1.f90: Add check for compile-time warning. Added: trunk/gcc/testsuite/gfortran.dg/io_constraints_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/direct_io_2.f90 trunk/gcc/testsuite/gfortran.dg/iomsg_1.f90 trunk/gcc/testsuite/gfortran.dg/iostat_2.f90 trunk/gcc/testsuite/gfortran.dg/label_4.f90 trunk/gcc/testsuite/gfortran.dg/open_access_append_1.f90 trunk/gcc/testsuite/gfortran.dg/pr20163-2.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21435
[Bug fortran/21435] fails to open nonexisting file with status scratch
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-13 08:22 --- And now, we even diagnose this at compile-time on mainline. Closing this PR accordingly. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21435
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-13 08:22 ---
Slightly less undefined, ICEs with -O -ftree-vrp -funswitch-loops:
void f(_Bool D917, int j0, int ubound1, int ubound5)
{
int i, j = j0;
int (*abc)[3];
i = 1;
while (1)
{
if (j <= 3)
while (1)
{
if (i != j)
{
if (ubound1 <= 0)
return;
(*abc)[1] = 0;
}
else
{
if (j > ubound1)
return;
if (ubound5 <= 0)
return;
}
j = j + 1;
if (D917)
break;
}
i = i + 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug fortran/29210] [4.1 only] Name parameter in complex constant not allowed in F95
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-13 08:33 --- Not worth a backport. Closing as fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug c++/29318] [4.0 Regression] ICE: type_info of pointer to VLA
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-10-13 08:34 --- Subject: Bug 29318 Author: mmitchel Date: Fri Oct 13 08:34:14 2006 New Revision: 117686 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117686 Log: PR c++/29318 * rtti.c (get_tinfo_decl): Refuse to create type info objects for variably modified types. PR c++/29318 * g++.dg/ext/vla4.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/vla4.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/rtti.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug c++/28506] [4.0/4.1/4.2 regression] ICE with initializers for functions
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-10-13 08:38 --- Subject: Bug 28506 Author: mmitchel Date: Fri Oct 13 08:38:43 2006 New Revision: 117687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117687 Log: PR c++/28506 * parser.c (function_declarator_p): New function. (cp_parser_init_declarator): Use it. (cp_parser_member_declaration): Likewise. PR c++/28506 * g++.dg/parse/pure1.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/pure1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
[Bug c++/28506] [4.0/4.1 regression] ICE with initializers for functions
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-10-13 08:40 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with initializers for |with initializers for |functions |functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #14 from paolo at gcc dot gnu dot org 2006-10-13 09:00 --- Subject: Bug 28277 Author: paolo Date: Fri Oct 13 09:00:31 2006 New Revision: 117689 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117689 Log: 2006-10-13 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/28277 (partial: ostream bits 2) * include/std/std_ostream.h (basic_ostream<>::_M_insert(const char_type*, streamsize)): New. (basic_ostream<>::_M_write(char_type, streamsize)): Likewise. (operator<<(basic_ostream<>&, _CharT), operator<<(basic_ostream<>&, char), operator<<(basic_ostream<>&, const _CharT*), operator<<(basic_ostream<>&, const char*)): Use the latter. * include/bits/ostream.tcc (basic_ostream<>::_M_insert(const char_type*, streamsize)): Define. (operator<<(basic_ostream<>&, const char*)): Use the latter. (operator<<(basic_ostream<>&, _CharT), operator<<(basic_ostream<>&, char), operator<<(basic_ostream<>&, const _CharT*), operator<<(basic_ostream<>&, const char*), operator<<(basic_ostream<>&, const basic_string<>&)): Remove. * include/bits/basic_string.h (operator<<(basic_ostream<>&, const basic_string<>&)): Use the latter, implement DR 586. * config/abi/pre/gnu.ver: Adjust, export the new _M_insert. * docs/html/ext/howto.html: Add an entry for DR 586. * testsuite/21_strings/basic_string/inserters_extractors/char/ 28277.cc: New. * testsuite/21_strings/basic_string/inserters_extractors/wchar_t/ 28277.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_character/char/ 28277-3.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_character/char/ 28277-4.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_character/wchar_t/ 28277-2.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_character/wchar_t/ 28277-3.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_character/wchar_t/ 28277-4.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/char/28277.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/28277.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/char/28277-3.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/char/28277-4.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-2.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-3.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-4.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/docs/html/ext/howto.html trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/ostream.tcc trunk/libstdc++-v3/include/std/std_ostream.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-13 09:18 ---
We end up comparing (GT_EXPR) i_92 with ubound1_111 which have the following
value ranges and equivalences:
i_92: [1, 3] EQUIVALENCES: { i_1 j_2 i_67 j_70 } (4 elements)
i_1: ~[0, 0] EQUIVALENCES: { } (0 elements)
j_2: VARYING
i_67: [1, ubound1_8] EQUIVALENCES: { i_1 } (1 elements)
j_70: [-INF, 3] EQUIVALENCES: { j_2 } (1 elements)
ubound1_111: [-INF, 0] EQUIVALENCES: { ubound1_8 ubound1_112 } (2 elements)
ubound1_8: VARYING
ubound1_112: [i_67, +INF] EQUIVALENCES: { ubound1_8 } (1 elements)
i_67 > ubound1_8 ([1, ubound1_8] > [ubound1_8, ubound1_8]) is false
i_67 > ubound1_111 ([1, ubound1_8] > [-INF, 0]) is true
i_92 > ubound1_111 ([1, 3] > [-INF, 0]) is true
So we have a cross-equivalency set inconsistency.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug fortran/29431] Not Implemented: complex character array constructors
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-13 09:20 --- Created an attachment (id=12422) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12422&action=view) This fixes the immediate problem of the lack of a character length. I find that, except for constant constructors, the need for padding is not detected at all. Thus the case above segfaults with this patch, unless supplied with enough elements. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29431
[Bug c/29449] New: OBJECT_FORMAT_ELF not defined for the AVR target
The preprocessor token "OBJECT_FORMAT_ELF" is incorrectly not defined for the AVR target (AVR-GCC). The AVR target uses the ELF object format, thus this token should be defined. Without the token, specifying the valid "-ffunction-sections" compiler switch causes AVR-GCC to incorrectly give the warning "-ffunction-sections may affect debugging on some targets". -- Summary: OBJECT_FORMAT_ELF not defined for the AVR target Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dean_camera at hotmail dot com GCC build triplet: 4.1.1 GCC host triplet: AVR GCC target triplet: N/A http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29449
[Bug fortran/29451] New: Fortran runtime error: Attempt to allocate a negative amount of memory...
Get following run-time message: > Fortran runtime error: Attempt to allocate a negative amount of memory. when running following program (fortran 90): !- program fred print*,'Calling jackal...' call jackal(1,0) call jackal(2,0) end subroutine jackal(b,c) integer :: b,c integer :: jello(b:c) print*,'In jackal',size(jello) if (size(jello) > 0 ) then jello = 9 print*,'jello = ',jello end if end subroutine jackal !- Above is compiled as "f90 tester.f90" on suse 9 linux box. Using GCC 4.2.0 20061012 (experimental). -- Summary: Fortran runtime error: Attempt to allocate a negative amount of memory... Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmason at ricardo dot com GCC build triplet: gcc version 4.2.0 20061012 (experimental) GCC host triplet: suse 9 GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29451
[Bug fortran/24767] gfortran: -Wno-unused-label does not work properly
--- Comment #2 from patchapp at dberlin dot org 2006-10-13 10:01 --- Subject: Bug number PR24767 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00694.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24767
[Bug fortran/29452] New: Do compile-time specifier checks for WRITE and READ
http://gcc.gnu.org/ml/fortran/2006-10/msg00241.html adds compile-time checking for the specifier arguments of CLOSE and OPEN. This should be done analogously for (cf. 9.5.1 in Fortran 2003) WRITE/READ (some only in READ allowed; some sre not yet implemented in gfortran): - ADVANCE: 'YES', 'NO' - ASYNCHRONOUS: 'YES', 'NO' - BLANK: 'NULL', 'ZERO' - DECIMAL: 'COMMA', 'POINT' - DELIM: 'APOSTROPHE', 'QUOTE', 'NONE - PAD: 'YES', 'NO' - ROUND: 'UP', 'DOWN', 'ZERO', 'NEAREST', 'COMPATIBLE'. 'PROCESSOR_DEFINED' - SIGN: PLUS, SUPPRESS, PROCESSOR_DEFINED -- Summary: Do compile-time specifier checks for WRITE and READ Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug fortran/29453] New: [g77 support] chmod intrinsic function not implemented in gfortran
I don't know whether anyone needs this, but g77 has according to
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77.pdf
this intrinsic function whereas gfortran only provides the subroutine.
program chmod_test
implicit none
intrinsic chmod
integer :: status
call chmod('test.dat','u=rwx',status)
print *, 'Status: ', status
print *, 'Status: ', chmod('test.dat','u=rwx')
end program chmod_test
--
Summary: [g77 support] chmod intrinsic function not implemented
in gfortran
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29453
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-13 10:07 --- It looks like we would need to recurse down into symbolic ranges in fix_equivalence_set, which would be far too costly. So a conservative fix for 4.2 is to just not record symbolic equivalencies at all. I wonder if there is a better way to deal with these issues than fix_equivalence_set though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug fortran/29452] Keyword check for specifiers in WRITE, READ and OPEN/CLOSE
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-13 10:13 --- Some tests show: open(13,file='foo',form='format') close(13,status='del') compiles and runs in gfortran. Expected: - A run-time error is shown. - A compile-time-error is shown (probably fixed by FX patch, not checked) * * * write(13,'(a)',advance='N') 'Hello:' This gives a compile-time error, whereas str = 'N' write(13,'(a)',advance=str) 'Hello:' gives not a run-time error. write(13,'(a)',advance='Not') 'Hello:' gives no compile-time error, but a run-time error. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Summary|Do compile-time specifier |Keyword check for specifiers |checks for WRITE and READ |in WRITE, READ and ||OPEN/CLOSE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug fortran/29454] New: Slightly wrong error message for IF statement
$ cat foo.f90 logical l(2) if (l) call abort end $ gfortran foo.f90 In file foo.f90:2 if (l) call abort 1 Error: ELSE IF clause at (1) requires a scalar LOGICAL expression -- Summary: Slightly wrong error message for IF statement Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29454
[Bug fortran/29454] Slightly wrong error message for IF statement
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-13 10:37:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29454
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-13 10:38 --- I have a patch to get rid of that beast completely. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-13 03:19:26 |2006-10-13 10:38:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-13 10:58 --- That works. Updated profile: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ks/call Ks/call name 11.26131.84 131.84 77379135 0.00 0.00 comptypes 11.05261.22 129.38 153228836 0.00 0.00 dump_aggr_type 7.47348.7087.48 441675354 0.00 0.00 pp_base_append_text 7.06431.3882.68 101695144 0.00 0.00 comp_template_args 6.90512.0980.71 870176 0.00 0.00 retrieve_specialization 6.09583.3271.24 116984878 0.00 0.00 template_args_equal 4.82639.7856.46 325283356 0.00 0.00 pp_base_character 4.56693.1053.3259058 0.00 0.00 ht_lookup 3.63735.5842.48 441675354 0.00 0.00 pp_base_string 3.30774.1838.60 287071962 0.00 0.00 dump_scope 3.20811.6337.46 10634496 0.00 0.00 dump_template_parms 2.99846.6535.02 133934524 0.00 0.00 dump_decl 2.82879.7133.06 153423130 0.00 0.00 dump_type 2.25905.9926.29 153344660 0.00 0.00 pp_c_type_qualifier_list 1.97929.0323.04 152685422 0.00 0.00 dump_template_argument 1.96951.9522.92 287215230 0.00 0.00 pp_c_identifier 1.35967.8115.86 3824263 0.00 0.00 purpose_member 1.34983.4915.68 153228836 0.00 0.00 class_key_or_enum_as_string 0.77992.52 9.03 115629446 0.00 0.00 pp_cxx_separate_with 0.68 1000.52 8.00 144377450 0.00 0.00 pp_cxx_colon_colon 0.60 1007.53 7.01 74128630 0.00 0.00 pp_base_last_position_in_text 0.47 1013.00 5.47 4619635 0.00 0.00 ggc_alloc_stat 0.43 1017.98 4.98 37063838 0.00 0.00 pp_cxx_end_template_argument_list 0.42 1022.89 4.92 2734603 0.00 0.00 tsubst 0.35 1026.98 4.09 37063838 0.00 0.00 pp_cxx_begin_template_argument_list 0.35 1031.07 4.09 574289 0.00 0.00 gt_ggc_mx_lang_tree_node 0.33 1034.88 3.81 218258 0.00 0.00 pp_base_emit_prefix 0.31 1038.56 3.68 6251202 0.00 0.00 ggc_set_mark 0.31 1042.21 3.66 10098142 0.00 0.00 pp_c_constant 0.28 1045.54 3.33 1473688 0.00 0.00 dfs_walk_all 0.28 1048.79 3.26 588277 0.00 0.00 lookup_template_class 0.27 1051.95 3.16 pp_base_newline 0.23 1054.67 2.72 10081686 0.00 0.00 pp_c_integer_constant 0.22 1057.22 2.55 1172353 0.00 0.00 lookup_field_1 0.22 1059.75 2.53 10101968 0.00 0.00 dump_expr 0.21 1062.20 2.45 4021108 0.00 0.00 dfs_access_in_type 0.21 1064.64 2.4448588 0.00 0.00 push_to_top_level 0.20 1066.97 2.34 8942686 0.00 0.00 cp_tree_equal 0.18 1069.12 2.15 615699 0.00 0.00 coerce_template_parms 0.17 1071.14 2.03 219438 0.00 0.00 reinit_cxx_pp 0.17 1073.11 1.97 214436 0.00 0.00 ht_lookup_with_hash 0.16 1075.00 1.89 128624 0.00 0.00 get_expr_operands 0.14 1076.60 1.60 609605 0.00 0.00 tsubst_aggr_type 0.13 1078.18 1.58 2662882 0.00 0.00 store_binding 0.13 1079.75 1.57 587010 0.00 0.00 instantiate_class_template 0.12 1081.19 1.452 0.00 0.00 dump_function_decl 0.12 1082.63 1.44 928019 0.00 0.00 tree_cons_stat 0.12 1084.03 1.40 709984 0.00 0.00 tsubst_template_args 0.12 1085.40 1.38 4639830 0.00 0.00 context_for_name_lookup 0.10 1086.59 1.19 2314384 0.00 0.00 htab_find_with_hash 0.09 1087.68 1.09 475135 0.00 0.00 lookup_fnfields_1 0.09 1088.74 1.0642858 0.00 0.00 finish_struct_1 0.09 1089.78 1.04 695522 0.00 0.00 htab_find_slot_with_hash 0.09 1090.81 1.03 10098142 0.00 0.00 pp_cxx_constant 0.09 1091.83 1.02 pp_c_conditional_expression -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Known to fail|4.0.4 4.1.2 |4.0.4 4.1.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-13 11:05 --- -O2 -ftime-report: Execution times (seconds) parser: 11.82 (14%) usr 0.54 (15%) sys 12.81 (14%) wall 254865 kB (62%) ggc name lookup : 62.00 (74%) usr 3.04 (82%) sys 64.50 (73%) wall 123819 kB (30%) ggc varconst : 7.37 ( 9%) usr 0.00 ( 0%) sys 7.50 ( 8%) wall 2369 kB ( 1%) ggc TOTAL : 84.28 3.7188.39 411895 kB ! (profile was also -O2) Not too much code is generated by the testcase (-O2): > size main.o textdata bss dec hex filename 21680 4 76 217605500 main.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/24784] Warning about unused routine argument should not read "unused variable"
--- Comment #2 from aldot at gcc dot gnu dot org 2006-10-13 11:46 --- Current trunk gives: # -Wall In file unused.f90:1 subroutine a(x) 1 Warning: Unused variable x declared at (1) # -Wall -W In file unused.f90:1 subroutine a(x) 1 Warning: Unused parameter x declared at (1) unused.f90:1: warning: unused parameter 'x' I'm looking into the improper diagnostic emitted by the FE for -Wall only, but to me it looks like that this is yet another case where the communication about diagnostics between FE and ME is misbehaving / not existing. In this case, the ME (function.c::do_warn_unused_parameter() to be specific) emits a diagnostic that was already dealt with by the FE. Shouldn't the diagnostic machinery use the FE's diagnostic infrastructure? Doing so would avoid to set TREE_NO_WARNING for stuff the FE did already diagnose. Apart from the above issue, the fortran frontend has it's own warning infrastructure and it's still unclear to me if it should use the generic one or not, at least in the long run. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24784
[Bug fortran/25923] [gfortran] garbled diagnostics with -O -Wuninitialized
--- Comment #3 from aldot at gcc dot gnu dot org 2006-10-13 11:54 --- To me this sounds more like a middle-end issue. The ME apparently doesn't have means to use language specific diagnosics hooks. Also see comment #2 for PR24784 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24784#c2 -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25923
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #13 from grayyoga at gmail dot com 2006-10-13 12:16 --- Subject: Re: using boost::MPL requires lots of memory But my main target is the previous testcase. It should at least provide me a C++ error, but not crash with internal error. On 13 Oct 2006 11:05:35 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-13 11:05 > --- > -O2 -ftime-report: > > Execution times (seconds) > parser: 11.82 (14%) usr 0.54 (15%) sys 12.81 (14%) wall > 254865 kB (62%) ggc > name lookup : 62.00 (74%) usr 3.04 (82%) sys 64.50 (73%) wall > 123819 kB (30%) ggc > varconst : 7.37 ( 9%) usr 0.00 ( 0%) sys 7.50 ( 8%) wall > 2369 kB ( 1%) ggc > TOTAL : 84.28 3.7188.39 > 411895 kB > > ! (profile was also -O2) > > Not too much code is generated by the testcase (-O2): > > > size main.o > textdata bss dec hex filename > 21680 4 76 217605500 main.o > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-13 12:18 --- Sure, but the crash is due to gcc running out of memory. And the third testcase is a good one to attack memory usage and compile-time problems on all of the three testcases. But don't hold your breath... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-10-13 12:20 --- Subject: Bug 29391 Author: fxcoudert Date: Fri Oct 13 12:20:28 2006 New Revision: 117691 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117691 Log: PR fortran/29391 * trans-intrinsic.c (gfc_conv_intrinsic_bound): Generate correct code for LBOUND and UBOUND intrinsics. * gfortran.dg/bound_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bound_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #15 from grayyoga at gmail dot com 2006-10-13 12:20 --- Subject: Re: using boost::MPL requires lots of memory Ok, if there is anything else I could help, please mail me. On 13 Oct 2006 12:18:51 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-13 12:18 > --- > Sure, but the crash is due to gcc running out of memory. And the third > testcase is a good one to attack memory usage and compile-time problems on all > of the three testcases. > > But don't hold your breath... > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/29391] [4.1 only] LBOUND and UBOUND are broken
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Known to fail|4.2.0 4.1.2 |4.1.2 Known to work||4.2.0 Summary|LBOUND(TRANSPOSE(I)) doesn't|[4.1 only] LBOUND and UBOUND |work|are broken Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #2 from falk at debian dot org 2006-10-13 12:43 --- >From the standard: [...] n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values. So the warning is justified (but not giving it twice). For the missing warning on the second memcpy, please file a second report since this is a totally different problem (and would require some aliasing analysis to detect). -- falk at debian dot org changed: What|Removed |Added Summary|unhelpful null argument |duplicated null argument |warning on memcpy() |warning on memcpy() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #7 from patchapp at dberlin dot org 2006-10-13 12:45 --- Subject: Bug number PR29446 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00698.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug c++/29455] New: Issues with -Wchar-subscripts
[This is both a C and C++ bug report, not sure how to classify that.]
int a[256];
int A(char c) { return a[c]; } // C and C++ warnings, OK.
int D(void) { return a['%'];} // Spurious C++ warning, no C warning
int B(void) { return a['Ã¥'];} // C++ warning, missing C warning
int C(void) { return a['\300']; } // C++ warning, missing C warning
So,
g++ -Wchar-subscripts warns "array subscript has type 'char'" about
arr['%'] even though the index is guaranteed positive. gcc does not.
OTOH, gcc does not warn about a['\300'] or a['Ã¥'] (8-bit a-ring), even
with -fsigned-char which ensures that the subscript is negative.
Note, arr['@'] COULD be a bug in the program with characters like @ which
are not in the basic execution character set: C99 5.2.1p3; I haven't got
the C++ standard. Only characters in that character set are guaranteed
to be positive: C99 6.2.5p3. If the program is intended to be portable
to other character sets, it is buggy. Even if gcc doesn't support a
machine with that charset - if anyone does these days:-) So it might
make sense to have a -Wchar-subscripts=2 warning which only assumes the
basic execution character set, not the current character set.
In preprocessor expressions I don't know if it should check the source
or execution character set, or both...
--
Summary: Issues with -Wchar-subscripts
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug fortran/29364] No error given if using a non-defined type in a type definition
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 29364 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #9 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 29373 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29407] namelist: overriding the host association does not work (rejects valid code)
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 29407 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
[Bug fortran/29232] No warning/error for duplicate construct name
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 29232 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29232
[Bug fortran/29422] ICE with allocatable
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 29422 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 27701 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug fortran/29428] Error in allocatable component function calls
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 29428 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29428
[Bug fortran/24398] invalid module file gives weird error
--- Comment #10 from pault at gcc dot gnu dot org 2006-10-13 12:51 --- Subject: Bug 24398 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug c/29062] unclear diagnostic for declaration after label
--- Comment #5 from falk at debian dot org 2006-10-13 12:52 --- I also think the diagnostics should be improved. -- falk at debian dot org changed: What|Removed |Added Severity|minor |enhancement Status|RESOLVED|UNCONFIRMED GCC host triplet|i486-linux | Keywords||diagnostic Known to fail||4.1.2 4.2.0 Resolution|INVALID | Summary|Parse error after label and |unclear diagnostic for |variable declaration|declaration after label http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug libfortran/29456] New: c99 functions provided by libgfortran
A few things will need to be changed on mainline after 4.2 branches: especially, we don't want separate erf.c and bessel.c files: they're C99 functions too. If anyone has other requests in this area, please add them here. -- Summary: c99 functions provided by libgfortran Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29456
[Bug libfortran/29456] c99 functions provided by libgfortran
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-13 13:05:40 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29456
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-10-13 13:19 --- The bootleneck is clearly using the diagnostic machinery for setting up DECL_NAME of the type decls. I wonder if we cannot directly compute and store mangled names in DECL_NAME which would save both time and memory... Any ideas? Mark? Jason? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug bootstrap/29457] New: make error when building on OpenUnix 8.5
When building gcc on Caldera OpenUnix 8.5 with the native compiler: configure: creating ./config.status config.status: creating Makefile config.status: creating testsuite/Makefile config.status: creating config.h config.status: executing default commands if [ x"" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir UX:make: ERROR: don't know how to make regex.c (bu42). *** Error code 1 (bu21) UX:make: ERROR: fatal error. *** Error code 1 (bu21) UX:make: ERROR: fatal error. /home/lmircea/kit/gcc-4.1.1>uname -a OpenUNIX T114p 5 8.0.0 i386 x86at Caldera UNIX_SVR5 -- Summary: make error when building on OpenUnix 8.5 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mircea_lutic at yahoo dot com GCC build triplet: OpenUNIX T114p 5 8.0.0 i386 x86at Caldera UNIX_SVR5 GCC host triplet: OpenUNIX T114p 5 8.0.0 i386 x86at Caldera UNIX_SVR5 GCC target triplet: OpenUNIX T114p 5 8.0.0 i386 x86at Caldera UNIX_SVR5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29457
[Bug fortran/29458] New: Spurious -Wuninitialized warning for implied do-loop counter
$ cat a.f90 integer :: n, i n = 5 n = sum((/(i,i=1,n)/)) end $ gfortran -O -Wall a.f90 a.f90: In function ‘MAIN__’: a.f90:3: warning: ‘i’ is used uninitialized in this function -- Summary: Spurious -Wuninitialized warning for implied do-loop counter Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-13 14:03:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug fortran/29459] New: Spurious warning about uninitialized optional arguments
gfortran -c -Wall -O1 gfort_warnings.f90 using gcc version 4.2.0 20061011 (experimental) on Windows XP for the code module foo_mod implicit none contains subroutine print_sub(fmt_acf,iu,labels) character (len=*), intent(in), optional :: fmt_acf integer , intent(in), optional :: iu character (len=*), intent(in), optional :: labels(:) if (present(iu)) then print*,iu end if if (present(fmt_acf)) then print*,fmt_acf end if if (present(labels)) then write (*,*) labels end if end subroutine print_sub ! end module foo_mod produces the spurious warnings gfort_warnings.f90: In function 'print_sub': gfort_warnings.f90:4: warning: 'stride.1' may be used uninitialized in this function gfort_warnings.f90:4: warning: 'ubound.0' may be used uninitialized in this function gfort_warnings.f90:4: warning: 'labels.0' may be used uninitialized in this function gfort_warnings.f90:4: warning: '' may be used uninitialized in this function -- Summary: Spurious warning about uninitialized optional arguments Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug c++/28506] [4.0/4.1 regression] ICE with initializers for functions
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-10-13 14:59 --- Subject: Bug 28506 Author: mmitchel Date: Fri Oct 13 14:59:00 2006 New Revision: 117695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117695 Log: PR c++/28506 * parser.c (function_declarator_p): New function. (cp_parser_init_declarator): Use it. (cp_parser_member_declaration): Likewise. PR c++/28506 * g++.dg/parse/pure1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/pure1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #8 from franke dot daniel at gmail dot com 2006-10-13 15:54 --- As requested in comment #7, a testcase for equal string lengths (identical to original PR but to_string() returns CHARACTER(len=255) instead of CHARACTER(len=32)): $> cat cat pr29267.f90 PROGRAM test_ice CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /)) CONTAINS CHARACTER(len=255) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT="(F6.3)") x END FUNCTION END PROGRAM $> gfortran-4.2 -g -Wall pr29267.f90 pr29267.f90: In function 'MAIN__': pr29267.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353 $> gfortran-4.2 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=$mylocalprefix --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,fortran --disable-nls --program-suffix=-4.2 Thread model: posix gcc version 4.2.0 20061013 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug java/29460] New: configure: error: libXtst not found, required by java.awt.Robot
I am trying to build java with gtk support. I configured with - ../gcc/configure --prefix=/usr/local/java --enable-languages=c,c++,java --enable-java-awt=gtk --enable-gtk-cairo --x-includes=/usr/x11R6/include --x-libraries=/usr/x11R6/lib And I get this output - checking for pkg-config... /usr/local/bin/pkg-config checking for gtk+-2.0 >= 2.4... yes checking GTK_CFLAGS... -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include checking GTK_LIBS... -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv checking for glib-2.0 >= 2.4 gthread-2.0 >= 2.4... yes checking GLIB_CFLAGS... -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include checking GLIB_LIBS... -L/usr/local/lib -lgthread-2.0 -lglib-2.0 -lintl -liconv checking for libart-2.0 >= 2.1... yes checking LIBART_CFLAGS... -I/usr/local/include/libart-2.0 checking LIBART_LIBS... -L/usr/local/lib -lart_lgpl_2 checking for XTestQueryExtension in -lXtst... no configure: error: libXtst not found, required by java.awt.Robot make[1]: *** [configure-target-libjava] Error 1 make: *** [all] Error 2 [dranta:~/gfortran/ibin] dir% ls /usr/X11R6/lib/libXtst.* /usr/X11R6/lib/libXtst.6.1.dylib/usr/X11R6/lib/libXtst.a /usr/X11R6/lib/libXtst.6.dylib /usr/X11R6/lib/libXtst.dylib Since libXtst is where it is supposed to be, it not clear what the problem is. -- Summary: configure: error: libXtst not found, required by java.awt.Robot Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
[Bug fortran/29451] Fortran runtime error: Attempt to allocate a negative amount of memory...
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-10-13 16:24 --- Not specific to Suze, Confirmed on i686-linux. Interesting bug. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-13 16:24:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29451
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from "C"
--- Comment #11 from pcarlini at suse dot de 2006-10-13 16:45 --- Benjamin, I'm seeing these failures: http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00654.html http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00575.html Are you sure the patch is ok wrt "source-less" (I don't remember the exact name of the procedure, sorry) testing (Codesourcery testing, in other terms)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-13 16:54 --- 'a' in C is not of the type char but instead int so not warning there is correct really. Also you forgot one thing '%' does not have to match up with the ANSI character set so it could be negative in signed char which means char (which could default to signed char) would be different. Anyways the above expliation should resolve what is the current behavior GCC has with its warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
-- steven at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug debug/29461] New: inconsistent variable output
In this short program, compiled with -O2 -gdwarf-2 on powerpc-darwin with 'gcc
version 4.2.0 20061012':
struct s;
extern void func(struct s *);
void func2(void * s_p)
{
struct s * const ss = s_p;
func (ss);
func (ss);
}
debug output is generated which has the variable 's_p' live until just before
the second call to 'func', and has the variable 'ss' live from after the first
call to 'func' through the end of the function. (The ranges of 's_p' and 'ss'
overlap.)
This is lame. The variables have identical values, the debug information
should be able to explain their value everywhere in the function.
--
Summary: inconsistent variable output
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29461
[Bug ada/29462] New: Sign ignored on fixed point multiplication
The sign seems to be ignored when multiplying a named number with a fixed point
value. Converting the named number to a fixed point type seems to work around
the problem. See the example below:
with Ada.Text_IO;
procedure Test
is
type T is delta 0.1 range -1.0 .. 1.0;
X : constant := -1.0;
Y : T;
package T_IO is new Ada.Text_IO.Fixed_IO (T);
begin
Ada.Text_IO.Put ("X = "); T_IO.Put (X); Ada.Text_IO.New_Line;
Y := -1.0;
Ada.Text_IO.Put ("Y = "); T_IO.Put (Y); Ada.Text_IO.New_Line;
Ada.Text_IO.Put ("X * Y = "); T_IO.Put (X * Y); Ada.Text_IO.New_Line;
Ada.Text_IO.Put ("T (X) * Y = "); T_IO.Put (T (X) * Y);
Ada.Text_IO.New_Line;
end Test;
--
Summary: Sign ignored on fixed point multiplication
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dewi dot daniels at silver-software dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29462
[Bug debug/29461] inconsistent variable output
--- Comment #1 from geoffk at gcc dot gnu dot org 2006-10-13 17:44 --- Created an attachment (id=12426) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12426&action=view) .s output of compiling the example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29461
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-13 17:44 --- Note Mark has requested the priorities for new regressions stay at P3 so he can see the new regressions and prioritize them himself. Reverting back to P3 for that reason. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-10-13 17:49 --- mine -- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-11 02:46:10 |2006-10-13 17:49:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug bootstrap/29457] make error when building on OpenUnix 8.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-13 17:49 --- UX:make: ERROR: don't know how to make regex.c (bu42). Can you trying using GNU make which is a requirement to build GCC? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29457
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #42 from dberlin at gcc dot gnu dot org 2006-10-13 17:50 --- mine -- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-25 19:57:09 |2006-10-13 17:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation with structs due to new struct alias
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-10-13 17:51 --- Mine -- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-20 22:26:43 |2006-10-13 17:51:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug ada/29463] New: Value of a static expression of a decimal fixed point type must be a multiple of the smal
gcc Ada does not always check whether the value of a static expression of a decimal fixed point type is a multiple of the small. Aonix ObjectAda rejects the following program with the error message, "test.adb: Error: line 5 col 22 LRM:4.9(36), The value of a static expression of a decimal fixed point type must be a multiple of the small, Continuing" procedure Test is type T is delta 0.1 digits 2; X : constant := 0.01; Y : constant T := X; begin null; end Test; -- Summary: Value of a static expression of a decimal fixed point type must be a multiple of the smal Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dewi dot daniels at silver-software dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29463
[Bug fortran/29464] New: problem with duplicate USE, ONLY of procedure in INTERFACE
For the program module foo_mod implicit none interface twice module procedure twice_real end interface twice contains real function twice_real(x) real :: x twice_real = 2*x end function twice_real end module foo_mod program xfoo use foo_mod, only: twice,twice implicit none print*,twice(2.3) end program xfoo version gcc version 4.2.0 20061011 (experimental) of gfortran on Windows XP says In file xduplicate_use.f90:14 use foo_mod, only: twice,twice 1 Error: Symbol 'twice' referenced at (1) not found in module 'foo_mod' In the thread "USE, ONLY question" in comp.lang.fortran, most people thought that repetition in a USE, ONLY statement was standard-conforming. If "twice" is replaced with "twice_real" in program xfoo, it compiles and runs, giving the expected output. Vivek Rao -- Summary: problem with duplicate USE, ONLY of procedure in INTERFACE Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29464
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-13 19:19 --- Subject: Re: ICE in operand_subword_force, at emit-rtl.c:1353 franke dot daniel at gmail dot com <[EMAIL PROTECTED]> wrote on Fri, 13 Oct 2006: > As requested in comment #7, a testcase for equal string lengths (identical to > original PR but to_string() returns CHARACTER(len=255) instead of > CHARACTER(len=32)): Oh, that's what you meant with equal lengths :-) This is indeed not required by the standard. And indeed, this triggers the same bug: the ICE has nothing to do with the assignment, it is the code dealing with the array constructor that is making us ICE. Thanks! This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #16 from carlos at codesourcery dot com 2006-10-13 19:40 --- 1. Relocated compiler should not search configured prefix. http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html 2. Remove 'NONE' from computed paths http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00096.html 3. Relocated cpp should not search configured prefix. http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html These three patches should prevent the compile from searching the configured prefix for *all* types of files. Eric, your comments are appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-13 20:09 --- Subject: Bug 29446 Author: rguenth Date: Fri Oct 13 20:09:10 2006 New Revision: 117705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117705 Log: 2006-10-13 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/29446 * tree-vrp.c (fix_equivalence_set): Remove. (extract_range_from_assert): Do not call fix_equivalence_set. (debug_value_range): Print a newline. (compare_name_with_value): For equivalence sets with inconsistent value ranges conservatively bail out. (compare_names): Likewise. * gcc.dg/torture/pr29446.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr29446.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-13 20:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug libgcj/29460] configure: error: libXtst not found, required by java.awt.Robot
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-13 20:09 --- The config.log file in the appropriate build directory (the libjava target directory, or maybe the classpath subdir) will have more information -- the test program, the command line. Could you post that info here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #10 from kargl at gcc dot gnu dot org 2006-10-13 20:14 --- Committed the patch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
Someone broke bootstrap
On amd64-*-freebsd, I see gmake[3]: Entering directory `/usr/home/sgk/gcc/obj4x/gcc' /usr/home/sgk/gcc/obj4x/./prev-gcc/xgcc -B/usr/home/sgk/gcc/obj4x/./prev-gcc/ -B/home/sgk/work/4x/x86_64-unknown-freebsd7.0/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc4x/gcc -I../../gcc4x/gcc/. -I../../gcc4x/gcc/../include -I./../intl -I../../gcc4x/gcc/../libcpp/include -I/usr/local/include -I../../gcc4x/gcc/../libdecnumber -I../libdecnumber ../../gcc4x/gcc/tree-vectorizer.c -o tree-vectorizer.o cc1: warnings being treated as errors ../../gcc4x/gcc/tree-vectorizer.c: In function 'vect_can_force_dr_alignment_p': ../../gcc4x/gcc/tree-vectorizer.c:1532: warning: comparison is always true due to limited range of data type gmake[3]: *** [tree-vectorizer.o] Error 1 gmake[3]: Leaving directory `/usr/home/sgk/gcc/obj4x/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/usr/home/sgk/gcc/obj4x' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/usr/home/sgk/gcc/obj4x' gmake: *** [all] Error 2 -- Steve
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #3 from sebor at roguewave dot com 2006-10-13 21:02 --- You're right, I missed that. I confess I don't quite understand the rationale for this in the standard and I'm not aware of any plaform that causes problems for such calls but based on Doug Gwyn's response to my query the undefined behavior is intentional. Go figure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[Bug bootstrap/29402] Parallel make fails with --disable-bootstrap
--- Comment #4 from ghazi at gcc dot gnu dot org 2006-10-13 21:05 --- Hopefully last revision... http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00688.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2006- |patches/2006- |10/msg00684.html|10/msg00688.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
[Bug c/29465] New: warning for overlapping memcpy()
I would like to propose that gcc (in both C and C++ modes) issue a warning
for calls to memcpy() with overlapping regions of memory (known at compile
time) such as the one below since the behavior of such calls is undefined.
#include
int main ()
{
int i = 0;
memcpy (&i, &i, sizeof i);
return 0;
}
--
Summary: warning for overlapping memcpy()
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #4 from sebor at roguewave dot com 2006-10-13 21:09 --- I opened bug 29465 with a request for the new warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-13 21:14 --- One question is the duplicated warning a regression and is it a C++ front-end problem or also a C one too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[Bug c/29465] warning for overlapping memcpy()
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement GCC build triplet|all | GCC host triplet|all | GCC target triplet|all | Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465
[Bug c++/29466] New: pointless error on implicit destructor
The code:
#include
#include
class der1 : public std::exception { std::string s;};
int main() {
der1 d;
return 0;
}
gets you:
~/ootbc/common$ g++ foo.cc
foo.cc:3: error: looser throw specifier for 'virtual der1::~der1()'
/usr/include/c++/4.1.0/exception:58: error: overriding 'virtual
std::exception::~exception() throw ()'
I understand that the throw specification (an abortion in general IMO; why it
was ever adopted after the experience with CLU is beyond me) of an overload in
a
derived class but be a subset of the specifications in the overloaded functions
in the base class(es). However in the case of implicitly generated functions,
requiring the user to explicitly say:
~der1() throw() {}
in the derived class is just silly. It also introduces non-portable
implementation dependencies where, as here, the base class is a system class
with unknown and frequently changing throw specification that vary across
hosts.
Ivan
--
Summary: pointless error on implicit destructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
[Bug ada/29463] Value of a static expression of a decimal fixed point type must be a multiple of the smal
--- Comment #1 from laurent at guerby dot net 2006-10-13 21:31 --- Confirmed with gcc version 4.2.0 20060922 (experimental), GCC accepts-invalid here. Note: Y : constant T := 0.01; is correctly rejected with: test.adb:5:22: value has extraneous low order digits -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-10-13 21:31:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29463
[Bug ada/29462] Sign ignored on fixed point multiplication
--- Comment #1 from laurent at guerby dot net 2006-10-13 21:34 --- Confirmed with gcc version 4.2.0 20060922 (experimental) $ gnatmake test $ ./test X = -1.0 Y = -1.0 X * Y = -1.0 T (X) * Y = 1.0 -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-10-13 21:34:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29462
[Bug c++/29466] pointless error on implicit destructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-13 21:37 ---
Comeau also errors and I don't have access to the standard right at this moment
to double check.
"ComeauTest.c", line 3: error: exception specification for implicitly declared
virtual function "der1::~der1" is incompatible with that of
overridden function "std::exception::~exception"
class der1 : public std::exception { std::string s;};
^
(In reply to comment #0)
> It also introduces non-portable
> implementation dependencies where, as here, the base class is a system class
> with unknown and frequently changing throw specification that vary across
To reply to this part, you are incorrect in saying they are unknown and
changing throw specifications as the C++ standard defines them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
[Bug c++/29466] pointless error on implicit destructor
--- Comment #2 from igodard at pacbell dot net 2006-10-13 21:49 --- Fair enough w/r/t standard base classes if the standard does indeed define the throw specifications for each class's destructors. But the same dependency appears on any base class, whether standard, 3rd party, or locally written. That dependency is necessary for a destructor you actually write, but it's just silly to require it on the compiler generated ones. Can't the compiler generate the right throw specification? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
rodata truncated by two
I'm not sure this is the correct mailing list, but here goes. I was
trying to debug a program
and finally got down to the raw object file. Under certain circumstances,
constants in the .rodata
section of an object file are getting truncated. Here's the data:
Smallest C program that has the bug:
int ObjectLoad(void* vars,void* Object){
int x = (int)Object;
switch (x){
case 0:
printf("X is %i\n",x);
break;
case 1:
printf("X is %i\n",x);
break;
case 2:
printf("X is %i\n",x);
break;
case 3:
printf("X is %i\n",x);
break;
case 4:
printf("X is %i\n",x);
break;
case 5:
printf("X is %i\n",x);
break;
case 6:
printf("X is %i\n",x);
break;
case 7:
printf("X is %i\n",x);
break;
case 8:
printf("X is %i\n",x);
break;
case 9:
printf("X is %i\n",x);
break;
default:
printf("Some other x\n");
}
}
int main(int artc, char**argv){
}
Compiler Info and command line
gcc -c -o testobject.o testobject.c -g -Wall
gcc --version
->gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1)
hex dump of the truncated part
0ce0 2f 5a 08 2f 5a 08 2f 5a 08 2f 30 08 2f 30 08 2f
|/Z./Z./Z./0./0./|
0cf0 30 08 2f 30 08 2f 30 08 2f 30 bc 30 d7 02 06 00
|0./0./0./0.0|
0d00 01 01 00 00 58 20 69 73 20 25 69 0a 00 53 6f 6d |X is
%i..Som|
0d10 65 20 6f 74 68 65 72 20 78 00 00 00 24 00 00 00 |e other
x...$...|
0d20 3c 00 00 00 54 00 00 00 6c 00 00 00 84 00 00 00
|<...T...l...|
0d30 99 00 00 00 ae 00 00 00 c3 00 00 00 d8 00 00 00
||
0d40 ed 00 00 00 10 00 00 00 ff ff ff ff 01 00 01 7c
|...||
0d50 08 0c 04 04 88 01 00 00 14 00 00 00 00 00 00 00
||
0d60 00 00 00 00 10 01 00 00 41 0e 08 85 02 42 0d 05
|AB..|
0d70 24 00 00 00 00 00 00 00 10 01 00 00 14 00 00 00
|$...|
Are you can see the constant strings fall before the jump table later
filled in by the
the linker for use by the case statement. The jump table entries are
intact, but the
string "Some other x\n" is missing the trailing as well as the
terminating NULL.
Let me know if you need more data.
Jason Larsen
[EMAIL PROTECTED]
[Bug bootstrap/29402] Parallel make fails with --disable-bootstrap
--- Comment #5 from ghazi at gcc dot gnu dot org 2006-10-14 01:25 --- Subject: Bug 29402 Author: ghazi Date: Sat Oct 14 01:25:39 2006 New Revision: 117721 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117721 Log: PR bootstrap/29402 * Makefile.in (ALL_GTFILES_H): Use $(sort ...) instead of shell pipeline. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
[Bug bootstrap/29402] Parallel make fails with --disable-bootstrap
--- Comment #6 from ghazi at gcc dot gnu dot org 2006-10-14 01:46 --- Fixed. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail|4.2.0 | Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
[Bug libgcj/29460] configure: error: libXtst not found, required by java.awt.Robot
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-14 02:37 --- Can you attach config.log? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29460
[Bug c++/29466] pointless error on implicit destructor
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-14 03:02 --- (In reply to comment #2) > Can't the compiler generate the right throw specification? No because the C++ standard says it does but with respect to all functions it calls and not just the base class. 15.4/13: An implicitly declared special member function (clause 12) shall have an exception-specification. If f is an implicitly declared default constructor, copy constructor, destructor, or copy assingment operator, is implicit exception-specification specifies the type-id T if and only if T is allows by the exception-specification of a function directly invoked by f's implicitly defintion; f shall allow exception if __any__ function it directly invokes all exceptions, and f shall no exceptions if __every__ function it directly invoked allows no exceptions. (emphisis is mine). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29466
[Bug target/29250] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #8 from dje at gcc dot gnu dot org 2006-10-14 03:03 --- Subject: Bug 29250 Author: dje Date: Sat Oct 14 03:03:23 2006 New Revision: 117724 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117724 Log: 2006-10-13 David Edelsohn <[EMAIL PROTECTED]> Ian Lance Taylor PR middle-end/29250 * expr.c (expand_expr_real_1) : Change EXPAND_SUM modifier to EXPAND_NORMAL when recursing. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug target/29250] [4.0/4.1 Regression] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-14 03:34 --- A regression from 3.4.6, most likely exposed by the gimplifier or TER in out of SSA. I really want to say the gimplifier with respect of type casting. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.0.4 |4.0.4 Known to work||3.4.6 4.2.0 Summary|internal compiler error: in |[4.0/4.1 Regression] |extract_insn, at|internal compiler error: in |recog.c:2084|extract_insn, at ||recog.c:2084 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug other/29442] insn-attrtab has grown too large
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-14 03:39 --- > Compiling on a machine with the > specified Gentoo minimum of 64M is not practical. HEHEHEHEHEHEHEHE. 64MB is very very small ammount of memory really. Even the PS3 has 256MB. Oh and compiling GCC should not have a memory requirement so gentoo is doing something wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
[Bug java/21900] [4.1/4.2 Regression] debugging regression when debugging libgcj
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-14 03:44 --- It has been 3 months since this went into waiting, what is the status of this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21900
