[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-03 08:32 --- For READ(1,ERR=10) J ! Read beyond EOF there are two possible implementations one finds: ifort: forrtl: severe (24): end-of-file during read gfortran: Fortran runtime error: End of file g95: Internal Error: EOF condition not handled-- END= tag needed sunf95: End-of-file: -1 or NAG f95: error value g77: error value -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug c++/28284] [4.1 regression] ICE with invalid static const variable
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-12-03 10:20 --- Subject: Bug 28284 Author: reichelt Date: Sun Dec 3 10:19:59 2006 New Revision: 119462 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119462 Log: Backport: 2006-08-27 Simon Martin [EMAIL PROTECTED] PR c++/28284 * pt.c (fold_non_dependent_expr): Make sure expr is not dereferenced if it is NULL. * g++.dg/template/pr28284.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/pr28284.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-12-03 11:39 --- I'll fix it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-02 08:20:28 |2006-12-03 11:39:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29642] Fortran 2003: VALUE Attribute (call by value not call by reference for actual arguments)
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-03 12:45 --- Fixed in 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29642
[Bug c++/29022] [4.0 regression] ICE using operator int in invalid class hierarchy
--- Comment #10 from lmillward at gcc dot gnu dot org 2006-12-03 13:12 --- Subject: Bug 29022 Author: lmillward Date: Sun Dec 3 13:11:51 2006 New Revision: 119463 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119463 Log: PR c++/29022 PR c++/27316 PR c++/28740 * parser.c (cp_parser_class_head): Move processing of any base classes to... (cp_parser_class_specifier) ...here. Take an extra tree* parameter for the base classes. Only process them if the opening brace was found. PR c++/29022 * g++.dg/inherit/virtual1.C: New test. * g++.dg/inherit/virtual2.C: Likewise. PR c++/27316 * g++.dg/inherit/error3.C: New test. PR c++/28740 * g++.dg/inherit/error4.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/virtual1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/virtual2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/instantiate1.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.bugs/900121_05.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/27316] [4.0 Regression] ICE with two ill-placed expression
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-12-03 13:12 --- Subject: Bug 27316 Author: lmillward Date: Sun Dec 3 13:11:51 2006 New Revision: 119463 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119463 Log: PR c++/29022 PR c++/27316 PR c++/28740 * parser.c (cp_parser_class_head): Move processing of any base classes to... (cp_parser_class_specifier) ...here. Take an extra tree* parameter for the base classes. Only process them if the opening brace was found. PR c++/29022 * g++.dg/inherit/virtual1.C: New test. * g++.dg/inherit/virtual2.C: Likewise. PR c++/27316 * g++.dg/inherit/error3.C: New test. PR c++/28740 * g++.dg/inherit/error4.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/virtual1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/virtual2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/instantiate1.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.bugs/900121_05.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug c++/28740] [4.0 regression] ICE with invalid inheritance
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-12-03 13:12 --- Subject: Bug 28740 Author: lmillward Date: Sun Dec 3 13:11:51 2006 New Revision: 119463 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119463 Log: PR c++/29022 PR c++/27316 PR c++/28740 * parser.c (cp_parser_class_head): Move processing of any base classes to... (cp_parser_class_specifier) ...here. Take an extra tree* parameter for the base classes. Only process them if the opening brace was found. PR c++/29022 * g++.dg/inherit/virtual1.C: New test. * g++.dg/inherit/virtual2.C: Likewise. PR c++/27316 * g++.dg/inherit/error3.C: New test. PR c++/28740 * g++.dg/inherit/error4.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error3.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/virtual1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/virtual2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/error2.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/instantiate1.C branches/gcc-4_0-branch/gcc/testsuite/g++.old-deja/g++.bugs/900121_05.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28740
[Bug c++/29022] [4.0 regression] ICE using operator int in invalid class hierarchy
--- Comment #11 from lmillward at gcc dot gnu dot org 2006-12-03 13:12 --- Now fixed in 4.0.4. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/28740] [4.0 regression] ICE with invalid inheritance
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-12-03 13:13 --- Fixed in 4.0.4 as well. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28740
[Bug c++/27316] [4.0 Regression] ICE with two ill-placed expression
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-12-03 13:13 --- Fixed in 4.0.4 as well. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #16 from pault at gcc dot gnu dot org 2006-12-03 13:38 --- Created an attachment (id=12730) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12730action=view) This fixes the INTERFACE part of the problem. I have not regtested the full suite yet; just gfortran.dg/i* The two tests are called interface_x.f90 and interface_y.f90 because I have some other interface related patches that have already been sumbitted - I just cannot remember how many there are. This is one of this afternoon's tasks:-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libfortran/30056] Exceeding recl on direct access
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-03 13:59 --- I forgot to assign this to myself. I'll do this together with PR 30009. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-03 13:59:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30056
[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-12-03 14:06 --- (In reply to comment #6) For READ(1,ERR=10) J ! Read beyond EOF there are two possible implementations one finds: ifort: forrtl: severe (24): end-of-file during read Really? With ifort 8.1, I get $ cat end-of-file.f WRITE(1) 1 REWIND(1) READ(1) I READ(1,END=10) J print *,no error stop 10print *,error value end $ ifort -v ifort end-of-file.f ./a.out Version 8.1 error value I do think this is the correct behavior, and I'll take care to maintain this behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-03 14:17 --- READ(1,ERR=10) J ! Read beyond EOF ifort: forrtl: severe (24): end-of-file during read Really? Yes, really. Note: END /= ERR in the two examples. With ifort 8.1, I get READ(1,END=10) J error value -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-03 14:44 ---
This fixes the INTERFACE part of the problem.
I have not regtested the full suite yet; just gfortran.dg/i*
I just regression tested it on x86_64-unknown-linux-gnu.
I also tried to compile all_cp2k_gfortran.f90 -- and it compiles (gfortran -c)
ok.
The patch looks good -- and the test cases as well.
Just for completeness, the relevant part of the standard is:
C1209 (R1206) A procedure-name shall not specify a procedure that is specified
previously in any procedure-stmt in any accessible interface with the same
generic identifier.
Note that this does not fix everything as gfortran rejects also interface_y.f90
if I comment the call bl_copy(1.0, chr); if I understand the standard
correctly, the ambiguity is ok as long as one does not try to access bl_copy.
(And ifort/NAG f95 and sunf95 agree with me.)
Something which puzzles me is also the error message; one gets *twice*:
interface_y.f90:39.58:
USE f77_blas_extra ! { dg-error Ambiguous|interfaces }
1
Error: Ambiguous interfaces 'sdcopy' and 'recopy' in generic interface
'bl_copy' at (1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug bootstrap/30058] New: [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
Building libgfortran there dies, probably due to the extern inline patch:
.libs/signal.o(.text+0x0): In function `__sigaddset14':
: multiple definition of `__sigaddset14'
.libs/kill.o(.text+0x0): first defined here
.libs/signal.o(.text+0x75): In function `__sigdelset14':
: multiple definition of `__sigdelset14'
.libs/kill.o(.text+0x75): first defined here
.libs/signal.o(.text+0xec): In function `__sigismember14':
: multiple definition of `__sigismember14'
.libs/kill.o(.text+0xec): first defined here
.libs/signal.o(.text+0x154): In function `__sigemptyset14':
: multiple definition of `__sigemptyset14'
.libs/kill.o(.text+0x154): first defined here
.libs/signal.o(.text+0x185): In function `__sigfillset14':
: multiple definition of `__sigfillset14'
.libs/kill.o(.text+0x185): first defined here
collect2: ld returned 1 exit status
As an example, /usr/include/signal.h contains:
int sigemptyset __P((sigset_t *)) __RENAME(__sigemptyset14);
extern __inline int
sigemptyset(sigset_t *set)
{
__sigemptyset(set);
return (0);
}
--
Summary: [4.3 regression] bootstrap broken on i386-unknown-
netbsdelf2.0.2
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: i386-unknown-netbsdelf2.0.2
GCC host triplet: i386-unknown-netbsdelf2.0.2
GCC target triplet: i386-unknown-netbsdelf2.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug other/30055] [4.0/4.1 Regression] while(__builtin_expect()) pessimizes loop
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-03 15:49 --- Subject: Re: [4.0/4.1 Regression] while(__builtin_expect()) pessimizes loop pinskia at gcc dot gnu dot org writes: Fixed for 4.2.0: (...) Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|while(__builtin_expect()) |[4.0/4.1 Regression] Hm. When you mark it as [4.0/4.1 Regression], should FIXED mean fixed for 4.0/4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30055
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-12-03 16:14 --- Created an attachment (id=12731) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12731action=view) Tentative patch Would the attached patch work? I'm in no position to try it out right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug c++/30059] New: Wrong function selected
The attached program should print void func(int , int ) void func(int , int ) Instead it prints void func(T, T) [with T = int] void func(int, int) This causes efficiency bugs that are very difficult to detect. -- Summary: Wrong function selected Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30059
[Bug c++/30059] Wrong function selected
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-03 16:39 --- Created an attachment (id=12732) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12732action=view) Program exhibiting the described behavior -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30059
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #2 from paolo at gcc dot gnu dot org 2006-12-03 17:16 --- Subject: Bug 29989 Author: paolo Date: Sun Dec 3 17:15:46 2006 New Revision: 119467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119467 Log: 2006-12-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29989 * include/bits/stl_algobase.h: Remove min and max #undefs. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #3 from pcarlini at suse dot de 2006-12-03 17:16 --- Done. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug c++/30059] Wrong function selected
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-03 17:34 --- No GCC, is finally correct to what the standard mentions is right. *** This bug has been marked as a duplicate of 2922 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30059
[Bug c++/2922] [DR 197] two-stage lookup for unqualified function calls with type-dependent arguments
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-12-03 17:34 --- *** Bug 30059 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bagnara at cs dot unipr dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2922
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-12-03 17:42 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
The patch looks good -- and the test cases as well.
Great!
Just for completeness, the relevant part of the standard is:
C1209 (R1206) A procedure-name shall not specify a procedure that is
specified
previously in any procedure-stmt in any accessible interface with the same
generic identifier.
Thanks - I realised that there must be something like this because the
CP2K usage was accepted by other compilers and that it is logical that
it should be so.
Note that this does not fix everything as gfortran rejects also
interface_y.f90
if I comment the call bl_copy(1.0, chr); if I understand the standard
correctly, the ambiguity is ok as long as one does not try to access bl_copy.
(And ifort/NAG f95 and sunf95 agree with me.)
This is equally understandable. It SHOULD be easy to put this bit right.
Something which puzzles me is also the error message; one gets *twice*:
interface_y.f90:39.58:
USE f77_blas_extra ! { dg-error Ambiguous|interfaces }
1
hence the form of the dg-error above; I was less interested to put
this right than to have it accepting the correct code. This is not
unusual in such errors. Sometimes, sometimes I succeed in finding
out why!
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Component|bootstrap |target Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug c++/28284] [4.1 regression] ICE with invalid static const variable
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-03 17:51 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284
[Bug target/30040] -mtune=native could be improved for Core 2 Duo and Core Duo
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-03 17:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug c++/30060] New: Error/warning on invalid code (duplicate identifier for enum/class) should be more specific
enum crap {
foo = 1
};
class foo {
};
int main(int argc, char **argv)
{
foo *a=new foo;
}
results in
test.cpp: In function 'int main(int, char**)':
test.cpp:10: error: 'a' was not declared in this scope
test.cpp:10: error: expected type-specifier before 'foo'
test.cpp:10: error: expected `;' before 'foo'
Which does not describe the problem very well.
It would be nicer to get
test.cpp:5: error: 'foo' already declared
Or, analogous to another existing warning,
test.cpp:2: warning: declaration of enum value 'foo' shadows class 'foo'
--
Summary: Error/warning on invalid code (duplicate identifier for
enum/class) should be more specific
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30060
[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-12-03 18:56 --- I've looked at the F 2003 standard, and at least there the wording is clear: 9.10: # An end-of-file condition occurs in the following cases: # # (1) When an endfile record is encountered during reading of a file # for sequential access. This is not the case here, when we try to read too many items from a record. # (2) When an attempt is made to read beyond the end of an internal file. # # (3) When an attempt is made to read beyond the end of a stream file. So we need an error condition here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug c++/30060] Error/warning on invalid code (duplicate identifier for enum/class) should be more specific
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-03 18:56 --- Actually I think the error is clear once you remember * is also multiplication. so we have foo * a = new foo; Also I doubt we can improve the error message here. Cameau online gives basically the same error message: ComeauTest.c, line 10: error: identifier a is undefined foo *a=new foo; ^ ComeauTest.c, line 10: error: expected a type specifier foo *a=new foo; ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30060
[Bug c++/30060] Error/warning on invalid code (duplicate identifier for enum/class) should be more specific
--- Comment #2 from bero at arklinux dot org 2006-12-03 19:05 --- True, but the warning bit (test.cpp:2: warning: declaration of enum value 'foo' shadows class 'foo') should be doable (and would make the rest much easier to spot). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30060
[Bug preprocessor/30001] out-of-bounds access when processing empty file
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-03 19:34 --- Is this related to the standard requirement that a source file must end with a newline character? (and thus cannot be empty?) Not really. Confirmed: ==17881== Invalid read of size 1 ==17881==at 0x87F2933: _cpp_convert_input (charset.c:1631) ==17881==by 0x87FA178: read_file_guts (files.c:555) ==17881==by 0x87FA22E: read_file (files.c:582) ==17881==by 0x87FA361: should_stack_file (files.c:626) ==17881==by 0x87FA58C: _cpp_stack_file (files.c:704) ==17881==by 0x87FCB28: cpp_read_main_file (init.c:483) ==17881==by 0x80D3416: c_common_post_options (c-opts.c:1110) ==17881==by 0x85BDEB6: process_options (toplev.c:1568) ==17881==by 0x85BE818: do_compile (toplev.c:1994) ==17881==by 0x85BE8B1: toplev_main (toplev.c:2042) ==17881==by 0x8100F79: main (main.c:35) ==17881== Address 0x404C62F is 1 bytes before a block of size 1 alloc'd ==17881==at 0x40052ED: realloc (vg_replace_malloc.c:306) ==17881==by 0x8822F3F: xrealloc (xmalloc.c:179) ==17881==by 0x87F2923: _cpp_convert_input (charset.c:1625) ==17881==by 0x87FA178: read_file_guts (files.c:555) ==17881==by 0x87FA22E: read_file (files.c:582) ==17881==by 0x87FA361: should_stack_file (files.c:626) ==17881==by 0x87FA58C: _cpp_stack_file (files.c:704) ==17881==by 0x87FCB28: cpp_read_main_file (init.c:483) ==17881==by 0x80D3416: c_common_post_options (c-opts.c:1110) ==17881==by 0x85BDEB6: process_options (toplev.c:1568) ==17881==by 0x85BE818: do_compile (toplev.c:1994) ==17881==by 0x85BE8B1: toplev_main (toplev.c:2042) -- pinskia 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-12-03 19:34:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30001
[Bug target/30041] FAIL: gcc.target/i386/sse3-movddup.c (internal compiler error)
--- Comment #4 from uros at gcc dot gnu dot org 2006-12-03 19:40 --- Subject: Bug 30041 Author: uros Date: Sun Dec 3 19:40:06 2006 New Revision: 119468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119468 Log: PR target/30041 * config/i386/sse.md (*sse3_movddup): Use operands[0] and operands[1] in insn constraint. Correct type attribute to sselog1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30041
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #19 from paulthomas2 at wanadoo dot fr 2006-12-03 19:41 --- Subject: Re: [meta-bugs] ICEs with CP2K Tobias, Note that this does not fix everything as gfortran rejects also interface_y.f90 if I comment the call bl_copy(1.0, chr); if I understand the standard correctly, the ambiguity is ok as long as one does not try to access bl_copy. (And ifort/NAG f95 and sunf95 agree with me.) Do you think that the error in gfortran.dg/interface_1.f90 is correct? I have fix for the above that also stops the doubling of the error message. However, it breaks interface_1.f90 because there is no refernce to the generic interface 'ambiguous' and so, no error. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libfortran/30005] Open errors (not/already exists etc.): show also the file name
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-12-03 20:16 --- I have a patch for this testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30005
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #20 from pault at gcc dot gnu dot org 2006-12-03 21:01 --- Created an attachment (id=12733) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12733action=view) A further development of the patch This version now behaves in the same way as other compilers; the testcase interface_y.f90 now distinguishes interfaces that are referenced from those that are not and now gives a warning in interface_1.f90, rather than an error. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12730|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c/19976] integer division by zero in subexpression should be overflow
--- Comment #6 from manu at gcc dot gnu dot org 2006-12-03 21:02 --- (In reply to comment #3) Hi Manual, Manuel (or Manu) http://en.wikipedia.org/wiki/Manuel not manual: http://en.wikipedia.org/wiki/Manual :-) The real issue is that OPT_Wdiv_by_zero needs to be enabled by -pedantic in order to generate an error for -pedantic-errors, as requested by Joseph in comment #1. So, we just have to replace warning by pedwarn, don't we? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976
[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-12-03 21:02 --- Created an attachment (id=12734) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12734action=view) first attempt at a patch This should fix this PR, and PR 30056 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug c/19976] integer division by zero in subexpression should be overflow
--- Comment #7 from joseph at codesourcery dot com 2006-12-03 21:05 --- Subject: Re: integer division by zero in subexpression should be overflow On Sun, 3 Dec 2006, manu at gcc dot gnu dot org wrote: The real issue is that OPT_Wdiv_by_zero needs to be enabled by -pedantic in order to generate an error for -pedantic-errors, as requested by Joseph in comment #1. So, we just have to replace warning by pedwarn, don't we? No, because except in evaluated parts of constant expressions this is only runtime undefined and so must be accepted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976
[Bug target/30041] FAIL: gcc.target/i386/sse3-movddup.c (internal compiler error)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-03 21:08 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30041
[Bug middle-end/29887] wrong-code for errno handling on overflow/underflow
--- Comment #3 from manu at gcc dot gnu dot org 2006-12-03 21:12 --- (In reply to comment #2) The problem is that we believe we can handle all errno checking/setting via the expand_errno_check() routine which is not true for overflow/underflow but only for invalid arguments that result in a NaN. Is there underflow/overflow if the value is so small/big that we end up with zero/infinite? I am really confused about that. See for example bug 23572. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29887
[Bug target/30040] [4.2]:-mtune=native could be improved for Core 2 Duo and Core Duo
--- Comment #4 from hjl at lucon dot org 2006-12-03 21:13 --- Gcc 4.2 has the same problem. The backported patch is at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00127.html -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|-mtune=native could be |[4.2]:-mtune=native could be |improved for Core 2 Duo and |improved for Core 2 Duo and |Core Duo|Core Duo Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug target/30040] [4.2]:-mtune=native could be improved for Core 2 Duo and Core Duo
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-03 21:19 --- (In reply to comment #4) Gcc 4.2 has the same problem. So this is not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-03 21:32 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931
[Bug target/30040] [4.2]:-mtune=native is wrong for Core 2 Duo and Core Duo
--- Comment #6 from hjl at lucon dot org 2006-12-03 21:39 --- I never said it was a regression and I opened it against gcc 4.2.0 if you take a look. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.2]:-mtune=native could be|[4.2]:-mtune=native is wrong |improved for Core 2 Duo and |for Core 2 Duo and Core Duo |Core Duo| Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-03 21:41 --- Someone else is going to have to look into this as this works just fine on spu-elf. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 Regression] Too much |[4.2/4.3 Regression] Too |RAM used: __clz_tab[] linked|much RAM used: __clz_tab[] ||linked Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug target/30040] -mtune=native is wrong for Core 2 Duo and Core Duo
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-12-03 21:43 --- (In reply to comment #6) I never said it was a regression and I opened it against gcc 4.2.0 if you take a look. So what if you opened it against 4.2. It is not a regression and by own normal policy if it has been fixed on the mainline it has been fixed in general and only if someone can say it is ok to fix for 4.2, then it will be fixed but since it has been fixed on the mainline and this is not a regression, I am going to keep on closing this bug as fixed. Please read about what release schedules are and why they exist and why release branches should not bring in too many enhancements. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Summary|[4.2]:-mtune=native is wrong|-mtune=native is wrong for |for Core 2 Duo and Core Duo |Core 2 Duo and Core Duo Target Milestone|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30040
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #21 from burnus at gcc dot gnu dot org 2006-12-03 21:50 --- Do you think that the error in gfortran.dg/interface_1.f90 is correct? I have fix for the above that also stops the doubling of the error message. However, it breaks interface_1.f90 because there is no refernce to the generic interface 'ambiguous' and so, no error. See the explanation of Richard Main in http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/44aa13e0102ec83d interface_1.f90 *is* invalid. (Which is not detected by sunf95 and NAG f95, by the way; it is detected by ifort.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #19 from r dot schwebel at pengutronix dot de 2006-12-03 21:57 --- (In reply to comment #18) The patch is also needed on gcc-4_1-branch. Doesn't work: this happens when I add the patch to 4.1.1: [EMAIL PROTECTED]:/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.Toolchain-trunk/build-target/glibc-2.5/elf$ +PATH=/media/rscusb1_plain/tmp//armeb-xscale-linux-gnueabi/gcc-4.1.1-glibc-2.5-kernel-2.6.18/bin:/media/rscusb1_plain/tmp//armeb-xscale +-linux-gnueabi/gcc-4.1.1-glibc-2.5-kernel-2.6.18/usr/bin:$PATH armeb-xscale-linux-gnueabi-gcc dl-lookup.c -c -std=gnu99 -O2 -Wall +-Winline -Wwrite-strings -fmerge-all-constants -g -Wstrict-prototypes -pg -fexceptions -fasynchronous-unwind-tables -I../include +-I/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf +-I/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build -I../ports/sysdeps/arm/elf +-I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl -I../ports/sysdeps/unix/sysv/linux/arm/eabi +-I../ports/sysdeps/unix/sysv/linux/arm/nptl -I../ports/sysdeps/unix/sysv/linux/arm -I../ports/sysdeps/unix/sysv/linux +-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu +-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv +-I../sysdeps/unix/sysv -I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix +-I../ports/sysdeps/arm/eabi -I../ports/sysdeps/arm/nptl -I../ports/sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 +-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl -I.. -I../libio +-I. -nostdinc -isystem +/media/rscusb1_plain/tmp/armeb-xscale-linux-gnueabi/gcc-4.1.1-glibc-2.5-kernel-2.6.18/bin/../lib/gcc/armeb-xscale-linux-gnueabi/4.1.1/ +include -isystem +/media/rscusb1_plain/tmp//armeb-xscale-linux-gnueabi/gcc-4.1.1-glibc-2.5-kernel-2.6.18/sysroot-armeb-xscale-linux-gnueabi/usr/include +-D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPROF -o +/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/dl-lookup.op -MD -MP -MF +/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/dl-lookup.op.dt -MT +/media/rscusb1_plain/svn/oselas/toolchain/trunks/OSELAS.Toolchain-trunk/build-target/glibc-2.5-build/elf/dl-lookup.op /tmp/ccuNAGqV.s: Assembler messages: /tmp/ccuNAGqV.s:169: Error: junk at end of line, first unrecognized character is `,' Here's where the assember barfs (the second line): check_match.7984: .fnstart .LFB69: .file 2 do-lookup.h .loc 2 76 0 @ Nested: function declared inside another function. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 1, uses_anonymous_args = 0 .LVL19: .pad #4 str ip, [sp, #-4]! .LCFI4: .movsp ip, #4 --- add ip, sp, #4 The , #4 seems to be bogus. This is built with binutils 2.17. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-12-03 22:02 --- Would the attached patch work? I'm in no position to try it out right now. Thanks. Compilable version to be attached, tested on all Solaris versions for the 3 branches, results are as expected again. Why does the compiler need fmodl (and floorl) on non-C99 platforms? I was under the impression that the requirement for the long double variants had been lifted on these platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-12-03 22:03 --- Created an attachment (id=12735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12735action=view) Compilable version of previous patch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Attachment #12731|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #22 from burnus at gcc dot gnu dot org 2006-12-03 22:07 --- And here is the relevant part of the standard Fortran 2003, Section 11.2.1 (USE) [cf. also F95, Sec 11.3.2]: Two or more accessible entities, other than generic interfaces or defined operators, may have the same identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces and defined operators are handled as described in section 16.2.3. Except for these cases, the local identifier of any entity given accessibility by a USE statement shall differ from the local identifiers of all other entities accessible to the scoping unit through USE statements and otherwise. I don't see it right way, but Richard Main claims that alreay using use module1, only: ambiguous_symbol use module2 is enough to make it invalid (this is not even detected by ifort). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libfortran/30005] Open errors (not/already exists etc.): show also the file name
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-12-03 22:45 --- Created an attachment (id=12736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12736action=view) Preliminary patch This patch adds a few checks for types of errors on opening a file to give a more use friendly message. I will probably put together a helper function in error.c to do this in the final patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30005
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #20 from pbrook at gcc dot gnu dot org 2006-12-03 22:48 --- As mentioned in the original patch submission mail you need a newer gas. http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00805.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #23 from burnus at gcc dot gnu dot org 2006-12-03 22:49 --- (In reply to comment #20) now gives a warning in interface_1.f90, rather than an error. I think one can live with this - Lahey also gives only a warning. (ifort a warning; Richard says it is invalid.) However, one gets neither a warning nor an error for the following test case, which can be found in the Fortran 2003 standard, Section C.11.2: INTERFACE BAD8 ! this interface is invalid ! ! despite the fact that it is unambiguous ! SUBROUTINE S8A(X,Y,Z) REAL,OPTIONAL :: X INTEGER :: Y REAL :: Z END SUBROUTINE S8A SUBROUTINE S8B(X,Z,Y) INTEGER,OPTIONAL :: X INTEGER :: Z REAL :: Y END SUBROUTINE S8B END INTERFACE BAD8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- Comment #23 from mkoeppe at gmx dot de 2006-12-04 00:17 --- (In reply to comment #22) Shell script issue: While building in builddir/gcc there are 3 scripts generated: as, nm, collect-ld. These have a wrong header. When gmake fails, you need to modify the first line #!sh - #!/bin/sh and restart. Unfortunately I don't know where the right place for patching this is. Interix apparently cannot execute scripts starting with #!sh. I now found the source of this in config/mh-interix, which says SHELL=sh. At least on interix 3.5+ there is /bin/sh, so this line should be removed! It causes the build to fail, as #!sh scripts are now disabled for security reasons on interix. Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug bootstrap/29741] Fails to build bootstrap under solaris 10, i386
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-04 00:25 --- This: In file included from /usr/include/sys/signal.h:34, from /usr/include/signal.h:26, from ../../../libiberty/pex-unix.c:28: /usr/include/sys/siginfo.h:259: error: parse error before ctid_t /usr/include/sys/siginfo.h:292: error: parse error before '}' token Makes it sound like a bug in solaris's headers. Though I noticed we include signal.h before sys/types.h which might be the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29741
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04 01:29 --- Subject: Re: Shared libstdc++ fails to link This problem was introduced by this change: That makes less sense really, because this just changes how to deal with TREE_NOTHROW. This sounds like a latent bug really. The change does affect the EH table (diff attached). Hacking the assembler output for stdexcept, I find that it's the following reference that causes the error: .word L$FB0940 The TREE_NOTHROW change exposes a problem in HP ld that only can be fixed by HP and that's not going to happen. The TREE_NOTHROW change has been applied to 4.1, so we have a regression. However, it probably would be possible to trigger this problem even without the TREE_NOTHROW change (e.g., setting flag_non_call_exceptions). So, I think the only fix is to revert DWARF2 EH support on this target on 4.1 and later ;) I've debugged HP ld sufficiently to determine the nature of the problem. Weak symbol support is implemented on this target using COMDAT subspaces. When duplicates occur in a link, the HP linker nullifies symbol references to the second and latter occurences of symbols in the COMDAT subspace. It does this by changing the symbol type to ST_NULL. As a result, the references to omitted subspaces change from ST_DATA to ST_NULL. This triggers the DATA_ONE_SYM_FOR_PLAB error from HP ld when we hit a reference in the DWARF2 EH table to an omitted subspace. The message is actually somewhat misleading as we nominally started with a ST_DATA symbol and not a ST_CODE code symbol. Well, actually the symbol is a code symbol but the default is to treat code labels as data symbols! I tried changing the absolute reference to a plabel reference but this results in another problem. Attached is a simplified bit of assembler output from stdexcept.cc and a small hack to HP ld which might work around the problem. To trigger the problem, the assembled output from pr29487.s needs to included twice in a shared link. Dave --- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04 01:29 --- Created an attachment (id=12737) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12737action=view) --- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04 01:29 --- Created an attachment (id=12738) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12738action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/24598] Need to support odcctools and its ablity to use --prefix and libtool
--- Comment #3 from echristo at gcc dot gnu dot org 2006-12-04 02:10 --- Subject: Bug 24598 Author: echristo Date: Mon Dec 4 02:10:10 2006 New Revision: 119477 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119477 Log: 2006-12-03 Eric Christopher [EMAIL PROTECTED] PR target/24598 * config/t-slibgcc-darwin: Pass -install_name. * config/darwin.h (LINK_COMMAND_SPEC): Remove use of libtool. Only pass through options that the linker recognizes. (LINK_SPEC): Update comment. Translate options. (STARTFILE_SPEC): Add dylib1.o for shared libraries. * config/darwin9.h (LINK_COMMAND_SPEC): Ditto above. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/config/darwin9.h trunk/gcc/config/t-slibgcc-darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24598
[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-12-04 02:18 --- Patch reviewed and tested. Looks good to go. I assume you tested the part of the corrupted file somehow. I suppose we could right a test case uses stream I/O to build a bogus file and then try to read it and confirm that error. That could be another testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug c++/14329] [tree-ssa] badly formatted warnings for SRA replacements used uninitialized
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-12-04 02:24 --- Subject: Bug 14329 Author: pinskia Date: Mon Dec 4 02:24:42 2006 New Revision: 119478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119478 Log: 2006-12-03 Richard Henderson [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR C++/14329 * error.c (cp_printer) 'D': Handle DECL_DEBUG_EXPR. 2006-12-03 Richard Henderson [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR C++/14329 * g++.dg/warn/unit-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/unit-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug c++/14329] [4.1/4.2 only] badly formatted warnings for SRA replacements used uninitialized
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 Known to work||4.3.0 Summary|[tree-ssa] badly formatted |[4.1/4.2 only] badly |warnings for SRA|formatted warnings for SRA |replacements used |replacements used |uninitialized |uninitialized Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug c++/29632] [4.0/4.1/4.2/4.3 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug c++/29733] [4.1/4.2/4.3 regression] ICE on initialization of function type
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug libfortran/30005] Open errors (not/already exists etc.): show also the file name
--- Comment #3 from patchapp at dberlin dot org 2006-12-04 05:20 --- Subject: Bug number PR30005 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-12/msg00181.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30005
[Bug target/29682] ICE: in change_pattern, at haifa-sched.c:4066 with -O3 -msched-control-spec
--- Comment #3 from patchapp at dberlin dot org 2006-12-04 07:30 --- Subject: Bug number PR target/29682 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-12/msg00187.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29682
