[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2005-12-19 08:12 --- Removing patch keyword and reassigning it to nobody as my patch doesn't fix it and I won't have free time before january. Sorry for not doing this earlier. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug bootstrap/25470] [4.2 Regression] fixincludes/ subdirectory not cleaned by "make distclean"
--- Comment #3 from bonzini at gnu dot org 2005-12-19 08:28 --- Sorry to ask the question. Are you sure that this is a 4.2 regression and not a 4.1 regression as well? The fixincludes module is not bootstrapped, so there is very small (if any) chance that the toplevel changes in 4.2 have changed the behavior. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470
[Bug bootstrap/25476] [4.2 Regression] Fixincludes is run three times
--- Comment #2 from bonzini at gnu dot org 2005-12-19 08:40 --- I think this was some kind of merging hiccup because I found this in the ChangeLog: 2004-08-30 Paolo Bonzini <[EMAIL PROTECTED]> * configure.ac: Do not run fixincludes after stage1 during toplevel bootstrap. * configure: Regenerate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25476
[Bug bootstrap/25476] [4.2 Regression] Fixincludes is run three times
--- Comment #3 from bonzini at gnu dot org 2005-12-19 08:47 --- Indeed, Geoff removed the snippet in revision 90117 probably because he did not know what it was good for. I will reapply the patch. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-19 08:47:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25476
[Bug bootstrap/25476] [4.2 Regression] Fixincludes is run three times
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-19 08:54 --- (In reply to comment #3) > Indeed, Geoff removed the snippet in revision 90117 probably because he did > not > know what it was good for. I will reapply the patch. Well he moved it to the toplevel at the same time so it might cause something weird when he was testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25476
[Bug c/25491] gcc segfaults compiling very long expressions
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-19 10:22 --- Works with 4.1, needs 300MB ram and about 10s (-O0). Same for 4.0.x. Works for 3.4, too, with 178MB but takes a bit longer to compile. Are you sure you tried compiling without optimization? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25491
[Bug c++/25492] New: friend class nested in derived class problem
The following code can't be compiled by gcc 4.0.2:
class Base {
public:
class Nested {};
};
class Derived:public Base {
public:
class Nested {
public:
void m();
};
class AnotherNested {
friend class Nested; // gcc 4.0.2 takes it as 'Base::Nested'
//friend class Derived::Nested; // this is needed in order to
be compiled by gcc 4.0.2
#line 14
AnotherNested() {}
};
};
void Derived::Nested::m() {
#line 18
Derived::AnotherNested instance;
}
should the first friend decl refer to Base::Nested or Derived::Nested?
The code is refused by gcc 4.0.2:
a.cpp: In member function 'void Derived::Nested::m()':
a.cpp:14: error: 'Derived::AnotherNested::AnotherNested()' is private
a.cpp:18: error: within this context
because gcc 4 takes for granted the friend refers to Base::Nested.
However, e.g. gcc 3.4 takes it as Derived::Nested.
Declaring the friend the second way:
friend class Derived::Nested;
works in gcc 4.0.2, but it uses not-yet-fully-declared class Derived, which
e.g.
can't be compiled by VC 6.0.
--
Summary: friend class nested in derived class problem
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomas dot sieger at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25492
[Bug target/24306] [3.4/4.0/4.1/4.2 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-12-19 11:34 ---
We add some alignment fluff in the SSE type case. The following works as
expected:
#include
typedef int __attribute__ ((vector_size (16))) foo_t;
extern void abort(void);
struct s
{
_Complex double f[0];
} s1;
void
check (int x, ...)
{
int y;
va_list ap;
va_start (ap, x);
va_arg (ap, struct s);
y = va_arg (ap, int);
/* Expect output: 3 7 */
if (y != 7)
abort ();
}
int main()
{
check (3, s1, 7);
return 0;
}
.vars dump difference, working agains non-working:
--- t2.c.t96.vars 2005-12-19 12:22:09.0 +0100
+++ t.c.t96.vars2005-12-19 12:15:08.0 +0100
@@ -5,10 +5,12 @@
{
char * ap;
char * D.1699;
+ char * ap.0;
:
__builtin_va_start (&ap, 0, 0);
- D.1699 = ap;
+ ap.0 = ap;
+ D.1699 = ap.0 + 15B & -16B;
if (*(int *) D.1699 != 7) goto ; else goto ;
:;
We have a bug here in the generic builtins.c and the config/i386/i386.c variant
of gimplify_va_arg_expr - and I have a fix.
--
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|2005-10-11 14:02:39 |2005-12-19 11:34:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug middle-end/24306] [3.4/4.0/4.1/4.2 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-12-19 11:40 --- And this doesn't look target dependent. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug rtl-optimization/23837] [4.0 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #36 from amylaar at gcc dot gnu dot org 2005-12-19 12:01 --- While the patch will stop the bug from being triggered by the test case, it does not fix th underlying combiner bug. Any REG_NO_CONFLICT block could potentially be rendered invalid by an inappropriate instruction combination. The REG_NO_CONFLICT note must be removed when such a combination is made. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug other/25493] New: missed warning about possible loss of data during conversion.
unsigned foo(unsigned long long x, unsigned long long y) { return x/y; }
float bar(double x, double y) { return x/y; }
$ g++ -Wall -O2 -c tmp.cpp
why g++ doesn't warn users like similar to msvc ?
(warning: conversion from 'type1' to 'type2', possible loss of data)
--
Summary: missed warning about possible loss of data during
conversion.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: *
GCC host triplet: *
GCC target triplet: *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25493
[Bug other/25493] missed warning about possible loss of data during conversion.
-- pluto at agmk dot net changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25493
[Bug rtl-optimization/23837] [4.0 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #37 from steven at gcc dot gnu dot org 2005-12-19 12:36 --- That would be a different bug, and the fix would still be to not have a no-conflict block to begin with. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug c/25491] gcc segfaults compiling very long expressions
--- Comment #3 from geckosenator at gmail dot com 2005-12-19 13:31 --- (In reply to comment #2) > Works with 4.1, needs 300MB ram and about 10s (-O0). > Same for 4.0.x. > Works for 3.4, too, with 178MB but takes a bit longer to compile. > > Are you sure you tried compiling without optimization? > I have tested it myself with gcc 4.0.2 and it worked. I'm now told this isn't a problem on gcc 4.x.. so I'm no longer sure if I should report it as a valid bug. I have had other people test this on gcc 3.x with both failure and success. I think it depends how gcc is installed. I was not using optimizations when I tested it. thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25491
[Bug rtl-optimization/23837] [4.0 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #38 from joern dot rennecke at st dot com 2005-12-19 13:34 --- Subject: Re: [4.0 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine) steven at gcc dot gnu dot org wrote: >--- Comment #37 from steven at gcc dot gnu dot org 2005-12-19 12:36 >--- >That would be a different bug, and the fix would still be to not have a >no-conflict block to begin with. > > No, it's the same bug. combine rendering REG_NO_CONFLICT notes invalid. And you seem to advocate removing REG_NO_CLONFLICT notes from gcc altogether here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug rtl-optimization/25484] [4.2 Regression] Fix for PR25456 is wrong
--- Comment #2 from jbglaw at lug-owl dot de 2005-12-19 14:17 --- Fixed by Jörn Rennecke <[EMAIL PROTECTED]> in http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01424.html . -- jbglaw at lug-owl dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25484
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #13 from bonzini at gnu dot org 2005-12-19 14:24 --- David, ok to commit to 4.1 now? -- bonzini at gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches
--- Comment #24 from amylaar at gcc dot gnu dot org 2005-12-19 14:37 --- Subject: Bug 20070 Author: amylaar Date: Mon Dec 19 14:36:59 2005 New Revision: 108792 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108792 Log: * cfgcleanup.c: Temporarily revert patches for PR 20070 till Bernd comes back. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #12 from hjl at lucon dot org 2005-12-19 14:40 --- Can you tell me which check in fixes this bug for 4.0? -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #13 from grigory_zagorodnev at linux dot intel dot com 2005-12-19 14:41 --- Here is the small reproducer, extracted from cpu2000/191.fma3d, so you can update regression test base. CHARACTER RD*8 CHARACTER WR*8 CHARACTER(1) C1 RD='N 1' READ (RD(1:2),*) C1 WRITE (WR,*) 'passed' WRITE (*,*) WR END Fails with the message: At line 8 of file foo.f90 Fortran runtime error: End of record -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug fortran/25494] New: error in g77 documentation (all versions)
In particular, here: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/g77/Floating-point-Exception-Handling.html#Floating-point%20Exception%20Handling where it states: "... gcc -o libtrapfpe.a trapfpe.c and then use it by adding -trapfpe to the g77 command line when linking ..." Whe I try it I get /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/../../../crt1.o(.text+0x18): In function `_start': : undefined reference to `main' /tmp/ccC12cnM.o(.text+0xc): In function `trapfpe': : undefined reference to `feenableexcept' collect2: ld returned 1 exit status This is due to the fact that gcc does not produce an archive on the fly. One should do: gcc -c trapfpe.c ar rv libtrapfpe.a trapfpe.o Also linking is quoted incorrectly in the documentation. It should at least be "...-ltrapfpe..." ^ -- Summary: error in g77 documentation (all versions) Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: boschini at cilea dot it GCC host triplet: 2.4.21-32.0.1.EL.cernsmp scientific linux cern http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25494
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #14 from dje at watson dot ibm dot com 2005-12-19 15:32 --- Subject: Re: [4.1 Regression] ICE during kernel build. Okay. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug fortran/25494] error in g77 documentation (all versions)
-- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |toon at moene dot indiv dot |dot org |nluug dot nl Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-19 15:43:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25494
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-19 15:44 --- Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os > Could this be a dup of Bug 23585? It looks like it could be. Looking at the rtl generated for testB using a version of the compiler with 23585 fixed, I see the same rtl sequence after the end of the first loop in 54.barriers that we had with the compiler in September. However, the memory load no longer gets inserted into the delay slot in 55.dbr. Thus, I think this bug should be closed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug middle-end/23954] [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #17 from danglin at gcc dot gnu dot org 2005-12-19 15:47 --- *** This bug has been marked as a duplicate of 23585 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #26 from danglin at gcc dot gnu dot org 2005-12-19 15:47 --- *** Bug 23954 has been marked as a duplicate of this bug. *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug c++/25495] New: 4.1 regression, code rejected: can't find matching function
Ice for C++ 3.0 from ZeroC (http://www.zeroc.com/download.html, source code
available) doesn't compile anymore with GCC from the 4.1 branch. It compiled
fine with 4.0.1 and 4.0.2. I managed to reproduce the problem with the
following sample code:
class Dummy1;
class Dummy2;
void incRef(Dummy1*);
void incRef(Dummy2*);
template
class Handle
{
public:
Handle(T* r = 0) { incRef(r); }
};
namespace Test
{
class Process;
typedef ::Handle ProcessPrx;
}
void incRef(::Test::Process*);
void
m()
{
::Test::ProcessPrx process;
}
I'm getting the following error:
---
Main.cpp: In constructor 'Handle::Handle(T*) [with T = Test::Process]':
Main.cpp:24: instantiated from here
Main.cpp:11: error: no matching function for call to 'incRef(Test::Process*&)'
Main.cpp:4: note: candidates are: void incRef(Dummy1*)
Main.cpp:5: note: void incRef(Dummy2*)
---
If the definition of the 'Handle' template is moved at the top, it compiles
fine. The output of 'gcc -v -save-temps Main.cpp':
---
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-shared --enable-languages=c,c++
--prefix=/opt/gcc-4.1 --enable-threads=posix
Thread model: posix
gcc version 4.1.0 20051219 (prerelease)
/opt/gcc-4.1/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -E -quiet -v
-D_GNU_SOURCE Main.cpp -mtune=pentiumpro -fpch-preprocess -o Main.ii
ignoring nonexistent directory
"/opt/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0
/opt/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/i686-pc-linux-gnu
/opt/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward
/usr/local/include
/opt/gcc-4.1/include
/opt/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.0/include
/usr/include
End of search list.
/opt/gcc-4.1/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -fpreprocessed
Main.ii -quiet -dumpbase Main.cpp -mtune=pentiumpro -auxbase Main -version -o
Main.s
GNU C++ version 4.1.0 20051219 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051219 (prerelease).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64389
Compiler executable checksum: 6367aa9360ae7c92e39b7212b696b4ab
Main.cpp: In constructor 'Handle::Handle(T*) [with T = Test::Process]':
Main.cpp:25: instantiated from here
Main.cpp:11: error: no matching function for call to 'incRef(Test::Process*&)'
Main.cpp:4: note: candidates are: void incRef(Dummy1*)
Main.cpp:5: note: void incRef(Dummy2*)
--
Summary: 4.1 regression, code rejected: can't find matching
function
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit at zeroc dot com
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=25495
[Bug c++/25492] [4.0/4.1/4.2 Regression] friend class nested in derived class problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-19 16:39 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, rejects- ||valid Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-12-19 16:39:34 date|| Summary|friend class nested in |[4.0/4.1/4.2 Regression] |derived class problem |friend class nested in ||derived class problem Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25492
[Bug c++/25495] 4.1 regression, code rejected: can't find matching function
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-19 16:44 --- This is invalid C++ which was fixed to be rejected in 4.1.0. This is a dup of bug 2922 which was fixed in 4.1.0. *** 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=25495
[Bug c++/2922] [DR 197] two-stage lookup for unqualified function calls with type-dependent arguments
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-12-19 16:44 --- *** Bug 25495 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||benoit at zeroc dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2922
[Bug fortran/20836] Public derived type with private derived type component
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-19 17:25 --- This is fixed in all three branches; In file pr20836.f90:6 TYPE all_type 1 Error: The component 'info' is a PRIVATE type and cannot be a component of 'all_type', which is PUBLIC at (1) This was fixed by my patch of 2005-10-01 - I must have missed this PR. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20836
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Comment #6 from reichelt at gcc dot gnu dot org 2005-12-19 17:26 --- Subject: Bug 20552 Author: reichelt Date: Mon Dec 19 17:26:29 2005 New Revision: 108795 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108795 Log: PR c++/20552 Backport: 2004-03-08 Mark Mitchell <[EMAIL PROTECTED]> * decl.c (duplicate_decls): Don't check IDENTIFIER_ERROR_LOCUS. * g++.dg/ext/typeof10.C: New test. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/ext/typeof10.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/decl.c branches/gcc-3_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-12-19 17:28 --- Subject: Bug 20552 Author: reichelt Date: Mon Dec 19 17:28:30 2005 New Revision: 108796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108796 Log: PR c++/20552 * g++.dg/ext/typeof10.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/typeof10.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-19 17:29 --- Subject: Bug 20552 Author: reichelt Date: Mon Dec 19 17:29:41 2005 New Revision: 108797 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108797 Log: PR c++/20552 * g++.dg/ext/typeof10.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/typeof10.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Comment #9 from reichelt at gcc dot gnu dot org 2005-12-19 17:30 --- Subject: Bug 20552 Author: reichelt Date: Mon Dec 19 17:30:42 2005 New Revision: 108798 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108798 Log: PR c++/20552 * g++.dg/ext/typeof10.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/typeof10.C Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug c/2707] gcc does not warn on truncate
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-19 17:33 --- *** Bug 25493 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2707
[Bug other/25493] missed warning about possible loss of data during conversion.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-19 17:33 --- *** This bug has been marked as a duplicate of 2707 *** -- 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=25493
[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579
--- Comment #10 from reichelt at gcc dot gnu dot org 2005-12-19 17:34 --- Now also fixed on the 3.4 branch. Testcase also in 4.0 branch, 4.1 branch, and mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #15 from bonzini at gnu dot org 2005-12-19 17:46 --- patch committed to 4.1 branch as well. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #15 from bonzini at gnu dot org 2005-12-19 17:46 --- patch committed to 4.1 branch as well. --- Comment #16 from bonzini at gnu dot org 2005-12-19 17:46 --- Subject: Bug 25180 Author: bonzini Date: Mon Dec 19 17:46:15 2005 New Revision: 108799 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108799 Log: 2005-12-19 Paolo Bonzini <[EMAIL PROTECTED]> PR target/25180 * config/rs6000/predicates.md (logical_const_operand): Split out of logical_operand. (logical_operand): Use it. * config/rs6000/rs6000.md (cmp -> xor peephole2): Use logical_const_operand. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/predicates.md branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.md -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug other/22313] [4.1/4.2 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap without -g
--- Comment #21 from mmitchel at gcc dot gnu dot org 2005-12-19 17:55 --- This is a bootstrap failure, and there is an approved patch, so this should be fixed before release: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug tree-optimization/23202] [4.1/4.2 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-12-19 18:03 --- Is there a non-Fortran test case? (I'm going to leave this as P3 until I know the answer to that question.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23202
[Bug middle-end/23785] [4.1/4.2 Regression] 197.parser performance drop
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 18:05 --- I've marked this as P2. We should try to understand the problem, but inlining heuristics are notoriously hard to get right, so it's hard to be sure whether we're seeing a real bug in the compiler, or just a situation where we got lucky before. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug preprocessor/24976] [3.4/4.0/4.1/4.2 Regression] simple hexadecimal number and plus/minus and no space
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 18:07 --- Downgraded to P5, as this will never be a release-critical issue. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-19 18:08 --- We need to at least understand this problem before release: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 18:09 --- Serious problem on popular platform: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug target/25042] [3.4/4.0/4.1/4.2 Regression] __float128 ICE on x86
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-19 18:15 --- Crashes are bad: P2 for now. If it turns out that this is "just" an ICE-on-invalid, then we might downgrade the priority. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug fortran/25068] [4.0/4.1] IOSTAT should be default integer when -std=f95
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-12-19 18:16 --- Fortran issues are not release-critical: P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25068
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-12-19 18:29 --- (Why should we get 1? Upon entry to f, a will be 1, since 32769 will be reduced modulo 2^16. Then, b will be 1 - 32768, or -32767. I don't see why that should be converted to 1 -- but I certainly don't see why it should be 32768 either.) In any case, wrong-code: P1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug middle-end/25121] [4.1/4.2 Regression] libgcj misscompilation?
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org Component|other |middle-end Keywords||EH, wrong-code Summary|libgcj misscompilation? |[4.1/4.2 Regression] libgcj ||misscompilation? Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25121
[Bug middle-end/25121] [4.1/4.2 Regression] libgcj misscompilation?
--- Comment #4 from aph at gcc dot gnu dot org 2005-12-19 18:30 --- See http://gcc.gnu.org/ml/gcc/2005-12/msg00548.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25121
[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-12-19 18:32 --- Serious wrong code problem: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-19 18:36 --- (In reply to comment #8) > (Why should we get 1? Upon entry to f, a will be 1, since 32769 will be > reduced modulo 2^16. Then, b will be 1 - 32768, or -32767. I don't see why > that should be converted to 1 -- but I certainly don't see why it should be > 32768 either.) 32769 == 0x8001 . so a will not be 1. You are thinking it is reduced modulo 2^15. so c will be negative as 0x8001 is negative so we don't take the branch. and then we have 0x8001 + -0x8000 which is equal to 1. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
--- Comment #10 from kazu at codesourcery dot com 2005-12-19 18:38 --- Subject: Re: [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type Hi Mark, > (Why should we get 1? Upon entry to f, a will be 1, since 32769 will be > reduced modulo 2^16. Then, b will be 1 - 32768, or -32767. I don't see why > that should be converted to 1 -- but I certainly don't see why it should be > 32768 either.) > > In any case, wrong-code: P1. First, 32769 will be reduced to -32767. (int) -32767 + -(int)32768 = -65535. If we take the lowest 16 bits of -65535, we get 1, and that's what f should be returning. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-12-19 18:40 --- Fortran problems are not release critical: P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
--- Comment #11 from mark at codesourcery dot com 2005-12-19 18:40 --- Subject: Re: [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type Kazu Hirata wrote: > Hi Mark, > >> (Why should we get 1? Upon entry to f, a will be 1, since 32769 will be >> reduced modulo 2^16. Then, b will be 1 - 32768, or -32767. I don't >> see why >> that should be converted to 1 -- but I certainly don't see why it >> should be >> 32768 either.) >> >> In any case, wrong-code: P1. > > First, 32769 will be reduced to -32767. > (int) -32767 + -(int)32768 = -65535. > If we take the lowest 16 bits of -65535, we get 1, and that's what f > should be returning. I believe you. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug c++/25156] [3.4/4.0/4.1/4.2 Regression] wrong error message (int instead of bool)
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-19 18:44 --- A minor diagnostic issue: P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c/25161] [4.0/4.1/4.2 Regression] Internal compiler error (segfault) instead of error message
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-19 18:45 --- Since the code is invalid, this is not a huge problem, but still shoudl be fixed: P2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25161
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 18:48 --- Serious problem - but an ICE, not wrong code: P2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug target/25196] [4.0/4.1 Regression] i386: wrong arguments passed
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-19 18:50 --- Serious wrong code problem: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug driver/25208] [3.4/4.0/4.1/4.2 Regression] two outputs and -MMD
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-12-19 18:51 --- We should fix this -- but it's not release-critical, due to the fact that the double -o on the command-line is not a very common case. P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug target/23482] [ColdFire] ICE in in final_scan_insn
--- Comment #1 from pbrook at gcc dot gnu dot org 2005-12-19 18:53 ---
This also occurs in a couple of places in the gcc testsuite, eg.
gcc.c-torture/compile/20050303-1.c
Reduced C testcase below.
int crc(int nleft)
{
int toread;
unsigned char buf[(128 * 1024)];
toread = nleft ? nleft: 1;
return toread;
}
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-12-19 18:53:25
date||
Summary|g++ crash building for m5307|[ColdFire] ICE in in
|arch|final_scan_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23482
[Bug tree-optimization/25211] [4.1/4.2 Regression] verify_ssa ICE for mesa with -Os -ftree-loop-linear
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 19:07 --- I don't quite understand how likely we are to see this ICE; -Os -ftree-loop-linear seems like an obscure combination of flags. I'll call it P2 for now. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25211
[Bug c++/25260] [4.0/4.1/4.2 Regression] Forward explicit intantiation declaration doesn't mix well with static integral member
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-19 19:12 --- This is not valid code; the error message is correct. You asked for an instantiation of the entire class, which includes the static data member. There is no definition of the static data member available. You must write: template static const unsigned int A::n; to define the static data member, even though there is an in-class initialization. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25260
[Bug c++/25294] [4.0/4.1/4.2 Regression] Bogus "unterminated comment" error from #pragma comment
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 19:14 --- This needs fixing before release: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25294
[Bug c/25309] [3.4/4.0/4.1/4.2 Regression] ICE on initialization of a huge array
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-19 19:16 --- ICE on somewhat odd code: P2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-19 19:21 --- I would definitely like to see this resolved, but it will never be release-critical: P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
[Bug testsuite/25318] [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for excess errors) fails
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-19 19:22 --- Since this is just a testsuite failure, I've marked it as P5. However, we really do want to get as close to zero FAILs as possible, so I hope that someone will correct the testcase. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25318
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-19 19:24 --- ICE on very plausible code: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328
[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-19 19:26 --- Do we have a testcase for this bug on a primary/secondary platform, or is this something CRIS-specific? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25335
[Bug c++/25342] [3.4/4.0/4.1/4.2 Regression] internal compiler error: in lookup_member, at cp/search.c:1209
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-19 19:26 --- Should be fixed before release, if possible: P2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug c++/25364] [4.0/4.1/4.2 Regression] Internal compiler error in templated C++
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-12-19 19:30 --- Must be fixed: P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25364
[Bug c++/25369] [3.4/4.0/4.1/4.2 Regression] use of inline function in template class leads to undefined reference
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-19 19:33 --- Why is this marked as WAITING? We need to figure out whether this code is valid; given that it's from Boost, it probably is. In that case, we'll need to fix it. P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25369
[Bug c++/25417] [4.1/4.2 Regression] internal compiler error in check_initializer; hits clisp
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-19 19:35 --- I've marked this as P2. I wouldn't be overly optimistic about fixing it, though; the cast-to-object extension is proving to support in G++, especially as the middle end has ceased providing as much support. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25417
[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-19 19:37 --- Should be fixed before release, and it looks like we have an almost-patch. P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25432
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-19 19:37 --- Fortran bugs are never release critical: P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
-- zadeck at naturalbridge dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |zadeck at naturalbridge dot |dot org |com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug rtl-optimization/25483] [4.2 Regression] ICE on valid code with -O2 -fmove-loop-invariants
--- Comment #7 from zadeck at naturalbridge dot com 2005-12-19 19:43 --- I had messed up the original change to df.c. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
[Bug tree-optimization/24793] [4.1/4.2 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #10 from rakdver at gcc dot gnu dot org 2005-12-19 20:10 --- Subject: Bug 24793 Author: rakdver Date: Mon Dec 19 20:10:11 2005 New Revision: 108808 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108808 Log: PR tree-optimization/24793 * tree-ssa-loop-ivopts.c (get_ref_tag): Remember the original reference if there are subvars. * tree-ssa-operands.c (get_tmr_operands): Handle subvars. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc
--- Comment #4 from hp at gcc dot gnu dot org 2005-12-19 20:10 --- Incomplete analysis, can't reply to the second part of comment #3. "No" to the first part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25335
[Bug c/25496] New: [m68k] Compiled Code Segfaults
gcc -O2 -falign-loops=4 -fomit-frame-pointer -funroll-loops -o buggy buggy.c
$ ./buggy
DBname = >>English.xmg<<
Segmentation fault
If you drop any single one of the parameters, it works. Dropping -O2 to
-O1 also works.
I wasn't able to find a simpler file that illustrated the problem, but
the attached are pretty short.
This code works fine on the other debian ports.
$ gcc -v
Using built-in specs.
Target: m68k-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,treelang --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release m68k-linux-gnu
Thread model: posix
gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
onestring:
1,"debug:\n"
buggy.c:
#include
#include
#include
#define X_MAXNUM 1832
#define X_HEADER"CSOUND_STRINGS\n"
#define DEBUG (1)
long benlong(long lval) /* coerce a natural long into a bigendian long */
{
char benchar[4];
char *p = benchar;
*p++ = (char)(0xFF & (lval >> 24));
*p++ = (char)(0xFF & (lval >> 16));
*p++ = (char)(0xFF & (lval >> 8));
*p = (char)(0xFF & lval);
return(*(long *)benchar);
}
/* String file will have a header string (X_HEADER) and then 10 characters
making a language for identification
*/
int main(int argc, char **argv)
{
char buff[256];
long strings[X_MAXNUM];
long loc, baseloc;
int j;
int n;
long item = 0;
FILE *db;
FILE *raw;
char dbname[16];
char lang[30] = {'E', 'n', 'g', 'l', 'i', 's', 'h', '\0'};
int order = ('t'<<24)|('x'<<16)|('t'<<8);
if (argc>=2) raw = fopen(argv[1], "rb");
else raw = fopen("onestring", "rb");
if (raw == NULL) {
fprintf(stderr, "Failed to open input file\n");
exit(1);
}
if (argc==3) {
/* 7 is length of `English' and there are 10 maximum */
int len = strlen(argv[2]);
if (len>29) len = 29;
strncpy(lang, argv[2], len);
memset(lang+len, '\0', 30-len); /* Null rest */
}
strcpy(dbname, lang); strcat(dbname, ".xmg"); /* ** */
if (DEBUG) fprintf(stderr, "DBname = >>%s<<\n", dbname);
db = fopen(dbname, "wb");
if (db == NULL) {
fprintf(stderr, "Failed to create DB file\n");
exit(1);
}
fwrite(&order, sizeof(int), 1, db);
fwrite(X_HEADER, sizeof(X_HEADER)-1, 1, db);
fwrite(lang, sizeof(char), 30, db);
n = X_MAXNUM;
n = benlong(n);
fwrite(&n, sizeof(long), 1, db);
baseloc = ftell(db);
for (j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25496
[Bug target/25496] [m68k] Compiled Code Segfaults
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-19 21:14 --- *(long *)benchar You are violating C aliasing rules as you are acessing a char array as a long (yes this is an aliasing violation, the opposite is not an aliasing violation that is acessing a long as a char is not an aliasing violation). Can you see if -fno-strict-aliasing "fixes" your problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25496
[Bug target/25496] [m68k] Compiled Code Segfaults
--- Comment #2 from stephen at marenka dot net 2005-12-19 21:21 --- It does not. I'll report the aliasing violation back to the csound maintainer. I wonder why it's only a problem on m68k. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25496
[Bug c++/25497] New: faults typedef redefinition in struct
+++ This bug was initially created as a clone of Bug #7869 +++
I stumbled over the second issue that the original bug report mentioned. I
think it was closed prematurely.
To clarify this a bit I provide my own short example.
It may be worth noting that comeau online does not produce any errors on this
code, nor does microsofts c++ compiler that comes with visual studio 8.
struct tag{};
struct A {
tag t; // *
typedef int tag;
};
*omit this declaration and everything is fine for g++
error msg on g++3.4.4:
error: declaration of `typedef int A::tag'
error: changes meaning of `tag' from `struct tag'
Why would the outer tag declaration conflict with the tag declaration in scope
A? This is not an error that I would have expected intuitively which is why I'd
like to bring this up again.
--
Summary: faults typedef redefinition in struct
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baraclese at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25497
[Bug c++/25497] faults typedef redefinition in struct
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-19 22:45
---
Subject: Re: New: faults typedef redefinition in struct
"baraclese at hotmail dot com" <[EMAIL PROTECTED]> writes:
| +++ This bug was initially created as a clone of Bug #7869 +++
|
| I stumbled over the second issue that the original bug report mentioned. I
| think it was closed prematurely.
| To clarify this a bit I provide my own short example.
| It may be worth noting that comeau online does not produce any errors on this
| code, nor does microsofts c++ compiler that comes with visual studio 8.
That does not make them "right", nor does it turn your invalid code
into valid code.
| struct tag{};
|
| struct A {
| tag t; // *
| typedef int tag;
| };
|
| *omit this declaration and everything is fine for g++
|
| error msg on g++3.4.4:
|
| error: declaration of `typedef int A::tag'
| error: changes meaning of `tag' from `struct tag'
|
| Why would the outer tag declaration conflict with the tag declaration in
scope
| A? This is not an error that I would have expected intuitively which is why
I'd
| like to bring this up again.
The C++ standard says that your program is ill-formed.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25497
[Bug c++/25497] faults typedef redefinition in struct
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-19 22:46 --- Actually this is still a violation of the standard. 3.3.6/1 item 2. Though no diagnostic is required for this case so GCC is correct to error out and so is Comeanu and Microsoft's compiler too. *** This bug has been marked as a duplicate of 3252 *** -- 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=25497
[Bug c++/3252] a struct member cannot have a name that is also a typedef
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-19 22:46 --- *** Bug 25497 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||baraclese at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3252
[Bug ada/25436] Ada bootstrap fail, SEGV in ggc_collect on x86-linux
--- Comment #3 from laurent at guerby dot net 2005-12-19 23:09 --- Ooops: Last known bootstrap: revision 108381 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25436
[Bug target/25042] [3.4/4.0/4.1/4.2 Regression] __float128 ICE on x86
--- Comment #3 from hubicka at gcc dot gnu dot org 2005-12-19 23:11 ---
testing patch:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 108753)
--- config/i386/i386.c (working copy)
*** ix86_function_regparm (tree type, tree d
*** 2179,2184
--- 2179,2186
/* Use register calling convention for local functions when possible.
*/
if (!TARGET_64BIT && !user_convention && decl
+ /* Libcalls pass IDENTIFIER_NODE as an decl. */
+ && TREE_CODE (decl) == FUNCTION_DECL
&& flag_unit_at_a_time && !profile_flag)
{
struct cgraph_local_info *i = cgraph_local_info (decl);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug c/25498] New: atof conversion error
char currConv[9]; float currConvf; memset(currConv, '\0', sizeof(currConv)); memcpy(currConv, '60342935', 8); currConv[8] = 0; currConvf = atof(currConv); // currConvf gets assigned value of 60342936 when string 60342935 is converted to float with atof // if currConvf is declared type double instead of float, the value is assigned // correctly: 60342935 (try in debugger) // Thanks. -- Summary: atof conversion error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mike dot c at u-s-merchants dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25498
[Bug tree-optimization/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #11 from steven at gcc dot gnu dot org 2005-12-19 23:18 --- Should be fixed on the trunk. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] ICE: |[4.1 Regression] ICE: |expected ssa_name, have |expected ssa_name, have |var_decl in verify_ssa, at |var_decl in verify_ssa, at |tree-ssa.c:746 |tree-ssa.c:746 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug c/25498] atof conversion error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-19 23:45 ---
This is called float not having enough precession. This is not a bug. Please
read what floating point is.
The full testcase looks like:
#include
#include
#include
int main(void)
{
char currConv[9];
float currConvf;
memset(currConv, '\0', sizeof(currConv));
memcpy(currConv, "60342935", 8);
currConv[8] = 0;
currConvf = atof(currConv);
printf("%f\n", currConvf);
}
-
--
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=25498
[Bug c/25498] atof conversion error
--- Comment #2 from mike dot c at u-s-merchants dot com 2005-12-20 00:21
---
Subject: RE: atof conversion error
Yes, but when I set the string to "60342935.00", I still get the same
result - 60342936 from atof() whereas if the covert to variable is
double (instead of float) I get the right result - 60342935.
I still think atof(##) should return the right result,
whatever the precision.
Thanks.
Mike Christen
[EMAIL PROTECTED]
310-261-1436
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Monday, December 19, 2005 3:46 PM
To: [EMAIL PROTECTED]
Subject: [Bug c/25498] atof conversion error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-19 23:45
---
This is called float not having enough precession. This is not a bug.
Please
read what floating point is.
The full testcase looks like:
#include
#include
#include
int main(void)
{
char currConv[9];
float currConvf;
memset(currConv, '\0', sizeof(currConv));
memcpy(currConv, "60342935", 8);
currConv[8] = 0;
currConvf = atof(currConv);
printf("%f\n", currConvf);
}
-
--
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=25498
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25498
[Bug c/25498] atof conversion error
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-20 00:40 --- 60342935.0 cannot be represented exactly in a float so this is still exacted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25498
[Bug c/25498] atof conversion error
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-20 00:40 --- oh, one more thing, GCC does not control atof at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25498
[Bug c/25498] atof conversion error
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-20 00:49 ---
Try the following program:
#include
int main(void)
{
float currConvf = 60342935.0;
printf("%f\n", currConvf);
}
And you will see that you get 60342936.0.
The number of bits needed to represent 60342935 is one too many to fit into
float.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25498
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2005-12-20 00:50 --- My apologies, I was looking at the wrong place. Grigory, thanks for test case. I have regression tested the patch and see no new failures. There are some NIST failures, but these are not affected by the patch. We have already fixed those failures in 4.1 and 4.2. I will commit the patch tonight as "obvious" Again, sorry for the confusion. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-20 00:50:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #13 from kkojima at gcc dot gnu dot org 2005-12-20 01:45 --- Subject: Bug 24982 Author: kkojima Date: Tue Dec 20 01:45:27 2005 New Revision: 108831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108831 Log: PR rtl-optimization/24982 * reload.c (refers_to_regno_for_reload_p): Take reg_equiv_invariant and reg_equiv_init into account. * reload.h (reg_equiv_invariant): Declare. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/reload.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug c++/24915] [3.4/4.0/4.1/4.2 Regression] Overload errors generated without template instantiations for class member templates
-- 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=24915
