[Bug target/19029] [4.0 Regression] ICE: unrecognizable insn:
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-17 08:01 --- It really seems to be a dup. Sorry for the noise. *** This bug has been marked as a duplicate of 18910 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19029
[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-17 08:01 --- *** Bug 19029 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910
[Bug c/19050] New: optimization bug in 4.0-20041212 snapshot
System in question is a 2GHz opteron running Fedora Core 2
Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041212/configure --disable-nls --with-system-zlib
--with-libiconv-prefix=/usr/local --program-suffix=40 --disable-shared --disable
-libgcj --disable-multilib
Thread model: posix
gcc version 4.0.0 20041212 (experimental)
The package at www.boo.net/~jasonp/gccbug.tar.bz2 contains
driver.c: driver program
graph.h: header with a few definitions
graph.c: contains code to find the number of vertices and connected
components of a very large graph. This is an excerpt from a
much larger source file, and contains the problem code
graph.dat: the input graph; contains 8 edges, each given by a pair
of integers in hex format. I'm sorry I can't get the input
set to be any smaller; the full dataset this came from is 20x
larger than this
This program prints out the computed number of connected components
for the graph described by graph.dat; compiling with
gcc40 *.c {-O1|-O2|-O3}
and running a.out yields '57670' as output. Compiling with 'gcc40 *.c'
or using gcc 3.4.1 with or without optimization, produces '57671' for
output. The difference is only 1 here, but for the full dataset it is
quite noticeably off.
The loop that I believe is responsible for the discrepancy starts at
graph.c:124 and is labeled with a comment that reads
/* OPTIMIZATION PRODUCES A BUG IN THIS LOOP */
Declaring the two variables above this comment to be volatile causes
the resulting code to work correctly with any level of optimization in
gcc 4.0...I've tried to understand the assembly code generated by the
compiler but it's a bit too convoluted for me.
I'll be happy to provide additional clarification if it's needed.
jasonp
--
Summary: optimization bug in 4.0-20041212 snapshot
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jasonp at boo dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19050
[Bug target/19051] New: m6811-elf-gcc ICE
gcc ICE when I did:
===
$ m6811-elf-g++ -Os -mshort -msoft-reg-count=32 -m68hc12 -c n.cpp
The ICE message is:
===
n.cpp: In function 'void getNewTableEntry()':
n.cpp:49: error: unable to find a register to spill in class 'D_REGS'
n.cpp:49: error: this is the insn:
(insn:HI 60 59 62 9 (set (reg:HI 59 [ D.1552 ])
(mult:HI (sign_extend:HI (reg:QI 63))
(sign_extend:HI (reg/v:QI 14 *_.d1 [orig:55 newIdx ] [55] 70
{mulqihi3} (insn_list:REG_DEP_TRUE 59 (nil))
(expr_list:REG_DEAD (reg/v:QI 14 *_.d1 [orig:55 newIdx ] [55])
(expr_list:REG_DEAD (reg:QI 63)
(expr_list:REG_EQUAL (mult:HI (sign_extend:HI (reg/v:QI 14 *_.d1
[orig:55 newIdx ] [55]))
(const_int 6 [0x6]))
(nil)
n.cpp:49: internal compiler error: in spill_failure, at reload1.c:1873
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
The m6811-elf-g++ 3.4.4 also generates same ICE.
$ ./m6811-elf-g++ --version
m6811-elf-g++ (GCC) 3.4.4 20041108 (prerelease)
Environment:
System: Linux namsh 2.6.10-rc3n2 #6 Tue Dec 14 15:50:33 KST 2004 i686 athlon
i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: m6811-unknown-none
configured with: ../configure --target=m6811-elf --prefix=/usr/GNUHCS
--program-prefix=m6811-elf- --with-gnu-ld --with-gnu-as --disable-shared
--enable-languages=c,c++ --without-headers --with-newlib --disable-nls
--disable-threads
How-To-Repeat:
Compile the code below with compiler option I described:
// n.cpp
extern signed char g_oldVal, g_newVal;
extern signed char g_base;
extern unsigned char tableA[], tableB[];
extern unsigned char g_AAval, g_APval;
extern unsigned char g_BAval, g_BPval;
extern unsigned int g_ARval, g_ABval;
extern unsigned int g_BRval, g_BBval;
typedef struct {
unsigned int r;
unsigned int b;
unsigned char a;
unsigned char p;
} TABLEENTRY;
void getNewTableEntry()
{
signed char oldIdx = g_oldVal, newIdx = g_newVal;
const signed char maxVal = ((44 * 2) + 6 * 2);
oldIdx += g_base;
newIdx += g_base;
if (oldIdx 0)
oldIdx = 0;
else if (oldIdx maxVal)
oldIdx = maxVal;
if (newIdx 0)
newIdx = 0;
else if (newIdx maxVal)
newIdx = maxVal;
if (oldIdx != newIdx)
{
TABLEENTRY *tablePtr;
tablePtr = (TABLEENTRY *) tableA + newIdx;
g_ARval = tablePtr-r;
g_ABval = tablePtr-b;
g_AAval = tablePtr-a;
g_APval = tablePtr-p;
tablePtr = (TABLEENTRY *) tableB + newIdx;
g_BRval = tablePtr-r;
g_BBval = tablePtr-b;
g_BAval = tablePtr-a;
g_BPval = tablePtr-p;
}
}
--- Additional Comments From namsh at kldp dot org 2004-12-17 08:34 ---
Fix:
The work-around is:
1. Remove one of the compiler options: -Os or -msoft-reg-count=32
2. Use 'int' instead of 'signed char' for oldIdx/newIdx.
--
Summary: m6811-elf-gcc ICE
Product: gcc
Version: 0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: namsh at kldp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m6811-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19051
[Bug tree-optimization/15678] [4.0 Regression] Compilation time increased by 10-20%
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-17 08:44 --- This would be a good time for new timings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15678
[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 08:54 --- Subject: Bug 17603 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 08:54:02 Modified files: gcc: ChangeLog gcc/config/i386: i386.c Log message: 2004-12-17 Jan Beulich [EMAIL PROTECTED] PR target/17603 * config/i386/i386.c (enum x86_64_reg_class): Define X86_64_COMPLEX_X87_CLASS. (x86_64_reg_class_names): Add name for X86_64_COMPLEX_X87_CLASS. (merge_classes): Handle X86_64_COMPLEX_X87_CLASS. (classify_argument): XCmode is X86_64_COMPLEX_X87_CLASS. (examine_argument): X86_64_COMPLEX_X87_CLASS requires two registers when dealing with a return value. (construct_container): Handle X86_64_COMPLEX_X87_CLASS. Eliminate impossible case of two X87/X87UP pairs (this now is being expressed by a single COMPLEX_X87). (x86_libcall_value): XCmode gets returned in st0/st1. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6866r2=2.6867 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gccr1=1.754r2=1.755 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603
Re: GCC C bug: sizeof a union of structs returns zero value
On Thu, Dec 16, 2004 at 06:52:35PM -0800, Hugh Daniel wrote:
char ccc[ sizeof( union{ struct aaa; struct bbb; })];
In ISO Standard C, this doesn't do what you think it does.
What you are attempting to use is an ill-conceived Microsoft
extension. You can enable *some* amount of support for this
in gcc by using -fms-extensions.
r~
[Bug libfortran/19052] unit 0 not preconnected to standard error
-- What|Removed |Added Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17 09:30 --- With 20041121, there was a problem with xeigtstc hanging with -O1 on IA-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug c++/19053] New: NRVO+virtual operator ICE
arta:~/c/proba$ cat nrvo-virtual-operator.cc
struct s {
virtual void operator *();
};
s f()
{
s result;
*result;
return result;
}
arta:~/c/proba$ g++-1212 nrvo-virtual-operator.cc
nrvo-virtual-operator.cc: In function 's f()':
nrvo-virtual-operator.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
zsh: 17566 exit 1 g++-1212 nrvo-virtual-operator.cc
arta:~/c/proba$ g++-1212 -v
Reading specs from /usr/local/gcc-1212/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041212/configure --prefix=/usr/local/gcc-1212 --
disable-checking
Thread model: posix
gcc version 4.0.0 20041212 (experimental)
arta:~/c/proba$ g++-1114 -c -Wall nrvo-virtual-operator.cc
arta:~/c/proba$ g++-1114 -v
Reading specs from /usr/local/gcc-1114/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041114/configure --prefix=/usr/local/gcc-1114 --
disable-checking
Thread model: posix
gcc version 4.0.0 20041114 (experimental)
arta:~/c/proba$ g++-3 -c -Wall nrvo-virtual-operator.cc
arta:~/c/proba$ g++-3 -v
Reading specs from /usr/local/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/gcc-3.4.3
Thread model: posix
gcc version 3.4.3
arta:~/c/proba$
--
Summary: NRVO+virtual operator ICE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benko at sztaki dot hu
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19053
[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-17 10:30 --- Further testing showed that this is a fallout from unit-at-a-time: [EMAIL PROTECTED]:~/tmp /opt/gcc/4.0-devel/bin/gcc -c test.c [EMAIL PROTECTED]:~/tmp nm test.o r bar V foo [EMAIL PROTECTED]:~/tmp /opt/gcc/4.0-devel/bin/gcc -c test.c -O2 [EMAIL PROTECTED]:~/tmp nm test.o U bar [EMAIL PROTECTED]:~/tmp /opt/gcc/4.0-devel/bin/gcc -c test.c -O2 -fno-unit-at-a-time [EMAIL PROTECTED]:~/tmp nm test.o r bar V foo The question still remains, what are the symantics? Do we have to declare the variable as extern or not? -- What|Removed |Added CC||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
--- Additional Comments From joseph at codesourcery dot com 2004-12-17 10:37 --- Subject: Re: [4.0 Regression] #pragma weak handling changes in 4.0.0 On Fri, 17 Dec 2004, aj at gcc dot gnu dot org wrote: The question still remains, what are the symantics? Do we have to declare the variable as extern or not? http://docs.sun.com/source/817-5064/sun.specific.html#48658 has the specification of #pragma weak for C, such as it is. It doesn't address your question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
[Bug target/19051] m6811-elf-gcc ICE
--- Additional Comments From namsh at kldp dot org 2004-12-17 11:04 --- I used m6811-elf-gccbug to report this bug. And I noticed the gcc version is disappeared. m6811-elf-gcc shows: Release: 4.0.0 20041216 (experimental) Why it changed to 0.0? Because of extra version string like 20041216 (experimental)? -- What|Removed |Added Version|0.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19051
[Bug libf2c/17636] truncation failed in endfile error when closing a file appended to
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 11:05 --- Fixing. -- What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Summary|[g77 only] truncation |truncation failed in |failed in endfile error|endfile error when closing |when closing a file appended|a file appended to |to | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17636
[Bug c++/17648] [3.3/3.4 Regression] template destructor was not called for inherited classes
--- Additional Comments From SWElef at post dot sk 2004-12-17 11:12 --- AFAICT the code in comment #5 is well-formed. std:12.4/5: An implicitly-declared destructor is implicitly defined when it is used to destroy an object of its class type... Thus, the declaration+definition of class ObjectList only declares ObjectList::~ObjectList() and the implementation is not permitted to define it yet, which also means that the implementation is not permitted to instantiate ListTObject::~ListT(). The definition of class Object again only declares Object::~Object(). The first place where a destructor is used is the body of the function test where Object::~Object() must be implicitly defined. It forces the implicit definition of ObjectList::~ObjectList() and finaly the instantiation of ListTObject::~ListT(). At this point, however, the class Object is already defined so there is no undefined behaviour. (See also std:14.7.1/9 which forbids early instantiation of non-virtual member functions including the discussed dtor.) Note that during the instantiation of ListTObject::~ListT() the expression delete array; involves a call to _inline_ Object::~Object() that has not been defined yet (it is just waiting to be defined after its member's dtor's implicit definition is completed). I can imagine that this may cause some problems for the implementation but it does not affect the validity of the code. (Note in 7.1.2/4: a call to the inline function may be encountered before its definition appears in the translation unit.) Regards, Vladimir Marko -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17648
[Bug libgcj/10353] [3.3/3.4/4.0 regression] Java testsuite failures Array_3, TLtest, Thread_Join, Thread_Wait_Interrupt Throw_2
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 11:22 --- On Solaris 7, 8 and 9 with 3.4.4pre, we are down to: 32-bit: === libjava tests === Running target unix FAIL: Array_3 execution - gij test FAIL: Array_3 execution - gij test === libjava Summary === # of expected passes3262 # of unexpected failures2 # of expected failures 10 # of untested testcases 10 64-bit: FAIL: Array_3 execution - gij test FAIL: Array_3 execution - gij test FAIL: FileHandleGcTest execution - source compiled test FAIL: FileHandleGcTest execution - gij test FAIL: FileHandleGcTest execution - bytecode-native test FAIL: FileHandleGcTest -O3 execution - source compiled test FAIL: FileHandleGcTest execution - gij test FAIL: FileHandleGcTest -O3 execution - bytecode-native test === libjava Summary === # of expected passes3249 # of unexpected failures8 # of expected failures 10 # of untested testcases 17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 11:41 --- I think I might have a fix for this -- What|Removed |Added AssignedTo|mark at codesourcery dot com|nathan at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 11:41 --- I think I might have a fix for this -- What|Removed |Added AssignedTo|nathan at codesourcery dot |nathan at gcc dot gnu dot |com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From giovannibajo at libero dot it 2004-12-17 12:07 --- Kriang, can you comment on my patch? Does it look correct to you? -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:23 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603
[Bug c++/19053] NRVO+virtual operator ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:32 --- This is a dup of bug 18984, I posted a patch already. *** This bug has been marked as a duplicate of 18984 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19053
[Bug c++/18984] [4.0 regression] ICE in check_pointer_types_r
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:32 --- *** Bug 19053 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||benko at sztaki dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18984
[Bug tree-optimization/19050] [4.0 Regression] optimization bug in 4.0-20041212 snapshot
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:38 --- I could reproduce it with 20041208 but with 20041214 it is fixed, can you test a newer GCC? -- What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |tree-optimization Keywords||wrong-code Summary|optimization bug in 4.0-|[4.0 Regression] |20041212 snapshot |optimization bug in 4.0- ||20041212 snapshot Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19050
[Bug libfortran/19052] unit 0 not preconnected to standard error
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:40 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 12:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
[Bug target/19051] m6811-elf-gcc ICE
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19051
[Bug c++/18829] Error signale on an unexisting line
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:55 --- /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h: In member function 'typename sigc:: adaptor_functorT_functor::result_type sigc::adaptor_functorT_functor::operator()() const [with T_functor = sigc::bound_mem_functor1void, IntroScene, bool]': /usr/include/sigc++-2.0/sigc++/functors/slot.h:89: instantiated from 'static T_return sigc::internal:: slot_call0T_functor, T_return::call_it(sigc::internal::slot_rep*) [with T_functor = sigc:: bound_mem_functor1void, IntroScene, bool, T_return = void]' /usr/include/sigc++-2.0/sigc++/functors/slot.h:96: instantiated from 'static void* (* sigc::internal:: slot_call0T_functor, T_return::address())(void*) [with T_functor = sigc::bound_mem_functor1void, IntroScene, bool, T_return = void]' /usr/include/sigc++-2.0/sigc++/functors/slot.h:438: instantiated from 'sigc::slot0T_return:: slot0(const T_functor) [with T_functor = sigc::bound_mem_functor1void, IntroScene, bool, T_return = void]' /usr/include/sigc++-2.0/sigc++/functors/slot.h:1090: instantiated from 'sigc::slotT_return, sigc:: nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil::slot(const T_functor) [with T_functor = sigc::bound_mem_functor1void, IntroScene, bool, T_return = void]' scene_intro.cpp:203: instantiated from here /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251: error: no match for call to '(sigc:: bound_mem_functor1void, IntroScene, bool) ()' /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1837: note: candidates are: T_return sigc:: bound_mem_functor1T_return, T_obj, T_arg1::operator()(typename sigc::type_traitT_arg3::take) const [with T_return = void, T_obj = IntroScene, T_arg1 = bool] /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251: error: return-statement with a value, in function returning 'void' mainly this: scene_intro.cpp:203: instantiated from here So fixed so closing as such. Also this is a most likely a dup of bug 11616. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18829
[Bug ada/19002] GNAT BUG DETECTED, unqualified record aggregate triggers
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 12:59 --- Confirmed: +===GNAT BUG DETECTED==+ | 4.0.0 20041208 (experimental) (powerpc-apple-darwin7.6.0) Assert_Failure sinfo.adb:2474| | Error detected at space_info.adb:19:48 [matter.ads:5:4] | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +== + -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 12:59:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19002
[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 13:00 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 13:00:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug middle-end/18897] [4.0 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: putchar (first referenced in build/gengenrtl.o) (data)
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 13:00:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18897
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From giovannibajo at libero dot it 2004-12-17 13:19 --- Wolfgang, I suggest you to bring this up in comp.std.c++, to get some official answer about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug tree-optimization/19042] Complex types are not SRA all the time.
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 13:36:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 13:38 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01260.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 13:44 --- I now think the code is ok, and both compilers are incorrect to reject any of the versions. The versions that do not contain user defined XYZ (const XYZ src) XYZ operator= (const XYZ src) functions are the problematic ones. In those cases, the compiler should synthesize suitable definitions of those functions. It correctly determines the CV qualifier of the SRC argument, but fails to generate the correct body. That body should be identical to the body supplied in the user-defined version. Namely copy construction or copy assignment of each member in turn. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
Re: GCC C bug: sizeof a union of structs returns zero value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My GCC sizeof a union of structs bug seems to be pilot error after
all...
So Hugh Redelmeier found the actual bug when we were looking at the
various details of memory allocation: we were not declaring any struct
identifiers to take the size of. This is the solution:
char ccc[ sizeof( union{ struct aaa; struct bbb; })];
char ccc[ sizeof( union{ struct aaa ; struct bbb ; })];
char ccc[ sizeof( union{ struct aaa Ignore_Me; struct bbb Ignore_Me_Too; })];
^ ^
One might argue that Draft n2794.txt 6.7 Declarations paragraphs
#2 and #6 are at odds in this case, one saying the lack of an
identifier is an error and the other saying it's optional. I leave
this for you to decide.
I will point out that the behavior of the C compiler has changed and
that this should be documented.
Thanks for GCC folks.
||ugh Daniel
-BEGIN PGP SIGNATURE-
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBQcLiZ1ZpdJR7FBQRAQKcmQQA67Lx2VmQ3/A6iBhTBVHFxPWQtzcNntg1
R8pZNawG1TmwbklELSl9WGWJP6v9wrUeqvdMzLTDhxQWFJACg972ExSFdUGmCg6+
nq21wDDFiMikTimYflM/XVSa0WV6ZXZHEHwP7gKe9bqOBmTsEuFWGmbsrj7H76X3
jjJHkpL9qpM=
=4XbY
-END PGP SIGNATURE-
[Bug c++/19054] New: Parse error in calls to template function members
// Just compile the following source
struct A {
template int n int get_n() { return n; }
};
template int n
struct B {
template int m int get_nm() { return n + m; }
};
struct C {
template int n
int get_n() { A a; return a.get_nn(); }
template int n
struct D {
int get_n()
{
A a;
return a.get_nn(); // Parse error here. It works under g++ 3.4
// Workaround: return a.A::get_nn();
}
template int m
int get_nm() { return n + m; }
template int m
int t() { return n + m; }
};
template int n, int m
int get_nm() { Bn b; return b.get_nmm(); }
template int n, int m
void t_m()
{
Dn wm;
wm.tm(); // parse error here
// Workaround: change function name form `t_m' to `t' !?!
}
};
int main()
{
A a;
B1 b;
C c;
C::D2 d;
a.get_n2();
b.get_nm2();
c.get_n2();
d.get_n();
c.t_m1,2();
return 0;
}
--
Summary: Parse error in calls to template function members
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dummy1 at gazeta dot pl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19054
[Bug c++/19054] Parse error in calls to template function members
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
13:54 ---
The first parse error is a dup of bug 795, which was fixed for 3.4 as you
pointed out and has a work
around which is just the same as fixing the next parse error which is a true
parse error.
The second one is not a bug in GCC but in your code since wm is type dependent,
there is not enough
information for the compiler to kown that wm.t is a template. The fix in the
source is:
template int n, int m
void t_m()
{
Dn wm;
wm.template tm(); // parse error here
// Workaround: change function name form `t_m' to `t' !?!
}
Note the template keyword, that is needed to tell the compiler/parser that wm.t
is a template.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19054
[Bug rtl-optimization/19055] New: Minor bit optimization with or and xor
The following two functions should produce the same assembly
int f(int a)
{
a|=1;
a^=1;
return a;
}
int f1(int a)
{
return a~1;
}
--
Summary: Minor bit optimization with or and xor
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
[Bug rtl-optimization/19055] Minor bit optimization with or and xor
-- What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
[Bug rtl-optimization/19055] Minor bit optimization with or and xor
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
14:25 ---
Another example where we don't get the optimization and f1 is still one
instruction (on 32bit PPC):
int f(int a,int b)
{
a|=b;
a^=b;
return a;
}
int f1(int a,int b)
{
return a=~b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
[Bug libfortran/19032] modulo generates wrong result for divisor 1 and -1
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17 14:27 --- I've adjusted the subject. I've had a look at the real modulo and mod case, but didn't quite understand it - it appeared to be overly complicated, compared to the straightforward formula a - floor(a/b)*b. I'm probably missing something. Also, here's a new test case. $ cat mod-array.f90 program main integer, parameter :: n=16 real, dimension(n) :: ar, br, modulo_result, floor_result integer, dimension(n) :: ai, bi , imodulo_result, ifloor_result ai(1:4) = 5 ai(5:8) = -5 ai(9:12) = 1 ai(13:16) = -1 bi(1:4) = (/ 3,-3, 1, -1/) bi(5:8) = bi(1:4) bi(9:12) = bi(1:4) bi(13:16) = bi(1:4) ar = ai br = bi modulo_result = modulo(ar,br) imodulo_result = modulo(ai,bi) floor_result = ar-floor(ar/br)*br ifloor_result = nint(real(ai-floor(real(ai)/real(bi))*bi)) do i=1,n if (modulo_result(i) /= floor_result(i) ) then print (A,4F5.0) ,real case failed: , ar(i),br(i), modulo_result(i), floor_result(i) end if if (imodulo_result(i) /= ifloor_result(i)) then print (A,4I5), int case failed: , ai(i), bi(i), imodulo_result(i), ifloor_result(i) end if end do end program main $ gfortran mod-array.f90 ./a.out real case failed:5. -1. -1. 0. int case failed: 5 -1 -10 real case failed: -5. 1. 1. 0. int case failed:-5110 real case failed:1. -1. -1. 0. int case failed: 1 -1 -10 real case failed: -1. 1. 1. 0. int case failed:-1110 -- What|Removed |Added Summary|modulo generates wrong |modulo generates wrong |result for divisor -1 |result for divisor 1 and -1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant
--- Additional Comments From jbeulich at novell dot com 2004-12-17 14:28 --- Now that I have an Itanium2 system to test with, I can confirm that the problem still exists in 3.4.3, and looking at the delta to 4.0.0's ia64.md there is no reason to believe the problem would have been fixed there. fnorm.d.s0 (as example, I tested with double) does set ar.fpsr.sf0.d, and thus would raise an exception if that was unmasked, and even if it's masked may confuse subsequent code in making it incorrectly assume some floating point operation happened on denormal input(s). -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7285
[Bug java/18931] jar - .so optimization problem
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 15:09 --- Subject: Bug 18931 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 15:09:12 Modified files: gcc/java : ChangeLog convert.h expr.c typeck.c Log message: 2004-12-17 Andrew Haley [EMAIL PROTECTED] PR java/18931 * typeck.c (convert): Use a CONVERT_EXPR when converting to BOOLEAN_TYPE or CHAR_TYPE. (convert_to_boolean, convert_to_char) : Remove. * convert.h (convert_to_boolean, convert_to_char) : Remove. * expr.c (expand_load_internal): Do type conversion if type is not as required. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1522r2=1.1523 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/convert.h.diff?cvsroot=gccr1=1.6r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gccr1=1.214r2=1.215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/typeck.c.diff?cvsroot=gccr1=1.73r2=1.74 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug libgcj/15001] Using JNI with interpreter and interface methods yields SIGSEGV
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 15:13 --- Subject: Bug 15001 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 15:13:44 Modified files: libjava: ChangeLog libjava/java/lang/reflect: natMethod.cc Log message: 2004-12-10 Andrew Haley [EMAIL PROTECTED] PR java/15001 * java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA): Look up abstract methods by name. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3261r2=1.3262 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/reflect/natMethod.cc.diff?cvsroot=gccr1=1.42r2=1.43 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15001
[Bug c/19056] New: 4.0 optimizes away a SEGV; 3.4.1 does not
A minimized test case:
int main() {
int y = 1;
int *x = y;
volatile int sum = 0;
while(1) {
sum += *x;
x++;
}
return 0;
}
Clearly, this should crash; under 3.4.1 it does. Under my checkout of a few
hours ago, however, it does not: instead, it enters an infinite loop (everything
inside the while(1) gets optimized away and we're left with just a jmp).
Workaround: make either x or sum volatile. This forces it to actually do the
computations inside the loop.
I'm not sure whether to view this as a compiler bug: this code is, at heart,
morally unbalanced. But it is a change in behaviour so I figured I'd report it.
--
Summary: 4.0 optimizes away a SEGV; 3.4.1 does not
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bh at techhouse dot brown dot edu
CC: gcc-bugs at gcc dot gnu dot org
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=19056
[Bug c/19056] 4.0 optimizes away a SEGV; 3.4.1 does not
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 15:18 --- The code is undefined, once you get into that, anything can happen so closing as invalid. We just optimize away the add and the load since the load is no longer needed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19056
[Bug c/19057] New: gcc-3_4-branch as of 2004/12/10 fails to compile linux 2.6.10-rc3-mm1 on x86
CC [M] fs/ncpfs/inode.o
fs/ncpfs/inode.c: In function `ncp_notify_change':
fs/ncpfs/inode.c:202: error: insn does not satisfy its constraints:
(insn 1089 333 335 19 include/asm/string.h:410 (parallel [
(set (reg:CCNO 17 flags)
(compare:CCNO (and:QI (reg:QI 5 di [orig:109 newmode ] [109])
(const_int -110 [0xff92]))
(const_int 0 [0x0])))
(set (reg:QI 5 di [orig:109 newmode ] [109])
(and:QI (reg:QI 5 di [orig:109 newmode ] [109])
(const_int -110 [0xff92])))
]) 205 {*andqi_2} (nil)
(expr_list:REG_UNUSED (reg:QI 5 di [orig:109 newmode ] [109])
(nil)))
fs/ncpfs/inode.c:202: internal compiler error: in copyprop_hardreg_forward_1,
at regrename.c:1549
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: gcc-3_4-branch as of 2004/12/10 fails to compile linux
2.6.10-rc3-mm1 on x86
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-ark-linux
GCC host triplet: i686-ark-linux
GCC target triplet: i686-ark-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
[Bug c/19057] gcc-3_4-branch as of 2004/12/10 fails to compile linux 2.6.10-rc3-mm1 on x86
--- Additional Comments From bero at arklinux dot org 2004-12-17 15:31 --- Created an attachment (id=7769) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7769action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
[Bug c/19057] gcc-3_4-branch as of 2004/12/10 fails to compile linux 2.6.10-rc3-mm1 on x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 15:32 --- This is a dup of bug 18932, which got fixed on the 12th. *** This bug has been marked as a duplicate of 18932 *** *** This bug has been marked as a duplicate of 18932 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
[Bug target/18932] [3.4/4.0 regression] ICE in copyprop_hardreg_forward_1, at regrename.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 15:32 --- *** Bug 19057 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18932
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 15:34 --- Here's a reduced testcase: === PR19030.cc:10: error: 'A' has not been declared PR19030.cc:11: error: 'A' has not been declared PR19030.cc:11: error: redefinition of 'int i' PR19030.cc:10: error: 'int i' previously declared here PR19030.cc:15: error: conflicting declaration 'struct N::A' PR19030.cc:5: error: 'struct N::A' has a previous declaration as 'struct N::A' PR19030.cc:15: internal compiler error: tree check: expected class 'declaration', have 'exceptional' (error_mark) in pushtag, at cp/name-lookup.c:4672 === -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|pentium3-pld-linux | GCC host triplet|pentium3-pld-linux | GCC target triplet|pentium3-pld-linux | Keywords||error-recovery, monitored Known to work|3.3.2 |3.3.5 3.4.3 Last reconfirmed|-00-00 00:00:00 |2004-12-17 15:34:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
15:35 ---
Oooops. That was the error message. ;-)
Here's the testcase:
===
struct A;
namespace N
{
struct A;
}
using namespace N;
int A::i;
int A::i;
namespace N
{
struct A;
}
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/17821] [3.4/4.0 Regression] Poor diagnostic for using . instead of -
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 15:58 --- Subject: Bug 17821 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 15:58:05 Modified files: gcc/cp : ChangeLog class.c cp-tree.h error.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: conv-5.C Log message: cp: PR c++/17821 * class.c (add_method): Do not push conversion operators into a binding level. * cp-tree.h (CLASSTYPE_PRIMARY_TEMPLATE_TYPE): Reformat. * error.c (dump_decl): TYPE_DECL case Remove extraneous braces. testsuite: PR c++/17821 * g++.dg/lookup/conv-5.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4539r2=1.4540 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gccr1=1.695r2=1.696 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1081r2=1.1082 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gccr1=1.273r2=1.274 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4773r2=1.4774 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/conv-5.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17821
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 16:00 --- 2004-12-17 Nathan Sidwell [EMAIL PROTECTED] PR c++/18721 * class.c (add_method): Do not push conversion operators into a binding level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c/19058] New: setjmp: 4.0 fails to give 'clobbered' warning (regression from 3.4.1)
In the code that follows, gcc-3.4.1 says:
gcc -W -Wall -Wno-unused-parameter qux.c -O2
qux.c:13: warning: variable 'x' might be clobbered by `longjmp' or `vfork'
gcc-4.0 with those same options gives no warning.
Note that neither version warns about 'sum' being clobbered.
#include signal.h
#include setjmp.h
#include stdio.h
static jmp_buf jmpbuf;
static void segv_handler(int sig) {
longjmp(jmpbuf, 1);
}
int main() {
int y = 1;
volatile int *x = y;
int sum = 0;
signal(SIGSEGV, segv_handler);
if(setjmp(jmpbuf) == 0) {
while(1) {
sum += *x;
x++;
}
}
printf(%d\n, sum);
return sum;
}
--
Summary: setjmp: 4.0 fails to give 'clobbered' warning
(regression from 3.4.1)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bh at techhouse dot brown dot edu
CC: gcc-bugs at gcc dot gnu dot org
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=19058
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 16:10 --- Fix for 3.4 branch 2004-12-17 Nathan Sidwell [EMAIL PROTECTED] PR c++/18975 * method.c (do_build_copy_constructor): Refactor. Don't const qualify a mutable field. (do_build_assign_ref): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17 16:17 --- fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c/19058] setjmp: 4.0 fails to give 'clobbered' warning (regression from 3.4.1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 16:18 --- This is because sum is not used outside of the loop with optimization turned on. We always use 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19058
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 16:19 --- Subject: Bug 18975 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-17 16:19:24 Modified files: gcc/cp : ChangeLog method.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: synth1.C Log message: cp: PR c++/18975 * method.c (do_build_copy_constructor): Refactor. Don't const qualify a mutable field. (do_build_assign_ref): Likewise. testsuite: PR c++/18975 * g++.dg/other/synth1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.185r2=1.3892.2.186 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.275.4.4r2=1.275.4.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.330r2=1.3389.2.331 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/synth1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18975] Copying objects with mutable non-static data members
--- Additional Comments From bangerth at dealii dot org 2004-12-17 16:34 --- Nathan, if this isn't a regression but a patch has been applied to the 3.4 branch, then you should also apply it to mainline. Otherwise you have just created a regression (3.4.4 will work as expected, but 4.0.0 will not). You therefore just came up with your own excuse to also commit the patch to present mainline (future 4.0.0). W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-17 16:44 --- The patch looks correct although the code is messy. With the patch, when is_friend is true and processing_specialization is false, we no longer count the number of template header to see if there are too many - but we've already done that in cp_parser_check_template_parameters. The code duplication in cp_parser_check_template_parameters and current_tmpl_spec_kind could be removed in GCC 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug c++/19030] [4.0 Regression] ice on tree check
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 17:11 --- Present on x86 and x86-64 too as of today on 3.4 branch. -- What|Removed |Added GCC target triplet|powerpc-redhat-linux| Last reconfirmed|2004-10-22 17:38:25 |2004-12-17 17:11:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16968
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
17:12 ---
Hi Nathan, the following patch fixes the ICE for me:
Index: gcc/gcc/cp/name-lookup.c
===
RCS file: /home/reichelt/GCC/CVS/gcc-cvs/gcc/gcc/cp/name-lookup.c,v
retrieving revision 1.101
diff -u -p -r1.101 name-lookup.c
--- gcc/gcc/cp/name-lookup.c9 Dec 2004 21:06:59 - 1.101
+++ gcc/gcc/cp/name-lookup.c17 Dec 2004 16:46:40 -
@@ -4663,7 +4663,12 @@ pushtag (tree name, tree type, int globa
pushdecl_class_level (d);
}
else
- d = pushdecl_with_scope (d, b);
+ {
+ d = pushdecl_with_scope (d, b);
+
+ if (d == error_mark_node)
+ return error_mark_node;
+ }
/* FIXME what if it gets a name from typedef? */
if (ANON_AGGRNAME_P (name))
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/18975] [4.0 regression] Copying objects with mutable non-static data members
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-17 17:21 --- Nathan, this is stage3, you *are* allowed to apply non-regression fixes. By not applying it there you've just created a new 4.0 regression... -- What|Removed |Added Known to fail|3.4.3 4.0.0 |4.0.0 Known to work||3.4.3 Summary|Copying objects with mutable|[4.0 regression] Copying |non-static data members |objects with mutable non- ||static data members http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18975] [4.0 regression] Copying objects with mutable non-static data members
-- What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug java/18931] jar - .so optimization problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 17:24 --- Fixed on the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug target/19059] New: Atmel AVR Tiny13 and Tiny2313 support corrupted
AtTiny13 and AtTiny2313 are considered as avr4 architecture. But they do not
support all the instructions of avr4.
For example the mul instruction does not exist. See bellow a test case for
mul.
avr-gcc -mmcu=attiny2313 test_mul.c
int main(void) {
uint8_t a, b;
uint16_t res;
res = a * b;
}
--
Summary: Atmel AVR Tiny13 and Tiny2313 support corrupted
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frouleau at naotek dot com
CC: ericw at evcohs dot com,gcc-bugs at gcc dot gnu dot org
GCC build triplet: Any
GCC host triplet: Any
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19059
[Bug tree-optimization/15678] [4.0 Regression] Compilation time increased by 10-20%
--- Additional Comments From belyshev at lubercy dot com 2004-12-17 17:57 --- 3.4.4 4.0.0 (*A) 4.0.0 (*B) deltaA deltaB time to compile one empty function, ms: cc1-O0 0.4334 0.5908 0.5836 36% 35% cc1plus-O0 0.6155 0.4700 0.4613 -24%-25% cc1-O2 0.8090 1.3886 1.3090 71% 62% cc1plus-O2 0.9213 1.4436 1.3767 57% 49% startup time, i.e. time to compile empty file, ms: cc1-O0 18.318.117.4 -1% -5% cc1plus-O0 22.221.020.4 -5% -8% cc1-O2 20.419.319.1 -5% -6% cc1plus-O2 23.722.321.7 -6% -8% *A -- gcc 4.0.0 20041217 compiled by gcc 3.4.4 20041217 *B -- gcc 4.0.0 20041217 compiled by itself. All errors are within 0.05 .. 0.5 % -- What|Removed |Added Last reconfirmed|2004-11-16 21:59:16 |2004-12-17 17:57:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15678
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Additional Comments From pmcnary at cameron dot net 2004-12-17 18:07 --- I have same problems building on OSR5 with UP3 and MP3. math.h unmatch #ENDIF same error as above for eh_alloc.cc Exact problem building 3.4.2 Building 3.3.x problem with math.h and unmatched #ENDIF and build stops compiling at eh_alloc.cc with syntax error at end of file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug libf2c/17636] truncation failed in endfile error when closing a file appended to
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 18:14 --- Patch at http://gcc.gnu.org/ml/fortran/2004-12/msg00177.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17636
[Bug libstdc++/19060] New: fstream.tellp() result not changed after some output
Program:
---8X---
#includefstream
int main() {
std::ofstream file(test.txt);
std::streampos startpos = file.tellp();
file 10;
std::streampos endpos = file.tellp();
assert(endpos != startpos);
return 0;
}
---X8---
compile at g++ 3.4.3 and work fine, but fail after compile at g++ 4.0.0
20041215 (mainline).
Also note: if set LD_LIBRARY_PATH point to gcc_34/lib (my gcc 3.4 lib
directory)
compiled with g++ 4.0 program work fine (using old gcc 3.4 shared libraries).
I think problem in code of libstdc++.so.6 or libgcc_s.so.1
Vladimir
--
Summary: fstream.tellp() result not changed after some output
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-freebsd5.3-RC1
GCC host triplet: i386-unknown-freebsd5.3-RC1
GCC target triplet: i386-unknown-freebsd5.3-RC1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:31 --- Created an attachment (id=7772) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7772action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:31 --- Created an attachment (id=7773) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7773action=view) .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 18:33 --- Hmm, it works for me on ppc-darwin with the mainline (20041215 and 20041214 and 20041213). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:44 --- First time i see this problem in september-october. Now i only fill PR. Program work for me only if it used gcc 3.4.x shared libraries. ~/pkg/gcc/bin/g++ test.cc setenv LD_LIBRARY_PATH $HOME/pkg/gcc_34/lib ./a.out setenv LD_LIBRARY_PATH $HOME/pkg/gcc/lib ./a.out Assertion failed: (endpos != startpos), function main, file test.cc, line 15. Abort (core dumped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug target/19061] New: ia64-hp-hpux11.23
The included program coredumps during execution when compiled with -O2 but not
when compiled with -O0. The problem appears to be with combine and the use of
the ptr_extend_plus_2 instruction. GCC is losing track of what is and isn't a
pointer. I am not entirely sure if the program is legal given all the casts.
struct magic_state {
void *mgs_sv;
};
typedef struct magic_state MGS;
MGS *PL_savestack;
void
restore_magic(void *p)
{
MGS* mgs = ((MGS*) ((char*)PL_savestack + (long)(p)));
if (!mgs-mgs_sv)
return;
mgs-mgs_sv = ((void *)0);
}
MGS s;
main()
{
PL_savestack = s;
restore_magic((void *) 0);
}
--
Summary: ia64-hp-hpux11.23
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 19:02 --- Please ignore my previous comment. The fix is not that easy. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug libfortran/19014] print *,maxloc(array) segfaults
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17 19:32 --- The assertion failure happens for me on an i686-pc-linux-gnu, as well. Looks like different bugs on different architectures for the same test case. (The assertion failure is a bug, too!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19014
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From nathan at codesourcery dot com 2004-12-17 19:38 --- Subject: Re: [4.0 Regression] ice on tree check reichelt at gcc dot gnu dot org wrote: --- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 19:02 --- Please ignore my previous comment. The fix is not that easy. :-( yes, it's harder. tracing in GDB shows wierdness happening before that point. nathan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug tree-optimization/18792] ICE with -O1 -ftree-loop-linear on small test case
--- Additional Comments From fjahanian at apple dot com 2004-12-17 19:40 --- Why hasn't been there be a resolution of this PR? It seems that all issues, including elimination of loop numbers, etc. have been taken care of. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18792
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
19:44 ---
Indeed, this can be demonstrated with the following testcase:
===
struct A;
namespace N
{
struct A;
}
using namespace N;
int A::i;
int A::i;
namespace N
{
struct C;
struct C {};
}
class D : N::C {};
===
With mainline I get the bogus error message:
PR19030.cc:10: error: 'A' has not been declared
PR19030.cc:11: error: 'A' has not been declared
PR19030.cc:11: error: redefinition of 'int i'
PR19030.cc:10: error: 'int i' previously declared here
PR19030.cc:16: error: conflicting declaration 'struct N::C'
^
PR19030.cc:15: error: 'struct N::C' has a previous declaration as 'struct N::C'
PR19030.cc:16: internal compiler error: tree check: expected class
'declaration', have 'exceptional' (error_mark) in pushtag, at
cp/name-lookup.c:4672
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug rtl-optimization/18942] Do loop is not as optimized as 3.3.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 20:15 --- Confirming as and removing regression marker as suggested by David. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 20:15:35 date|| Summary|[4.0 Regression] Do loop is |Do loop is not as optimized |not as optimized as 3.3.2 |as 3.3.2 Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942
[Bug fortran/17675] [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-17 20:42 --- I haven't tested this yet, but perhaps something as simple as Index: trans-common.c === RCS file: /cvsroot/gcc/gcc/gcc/fortran/trans-common.c,v retrieving revision 1.18 diff -u -p -r1.18 trans-common.c --- trans-common.c 16 Sep 2004 16:00:43 - 1.18 +++ trans-common.c 17 Dec 2004 20:41:48 - @@ -269,6 +269,9 @@ build_equiv_decl (tree union_type, bool TREE_ADDRESSABLE (decl) = 1; TREE_USED (decl) = 1; + DECL_ALIGN (decl) = BIGGEST_ALIGNMENT; + DECL_USER_ALIGN (decl) = 0; + /* The source location has been lost, and doesn't really matter. We need to set it to something though. */ gfc_set_decl_location (decl, gfc_current_locus); Would fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
[Bug c++/19034] [3.4/4.0 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:1633
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17 20:59 --- Nathan, this was caused by your patch http://gcc.gnu.org/ml/gcc-cvs/2003-06/msg00871.html Apparently we have a tcc_exceptional in the last switch statement of cp_tree_equal so that we hit gcc_unreachable. I don't know whether tcc_exceptional should be handled more gracefully or whether it shouldn't appear there at all. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19034
[Bug tree-optimization/18792] ICE with -O1 -ftree-loop-linear on small test case
--- Additional Comments From dberlin at dberlin dot org 2004-12-17 21:12 --- Subject: Re: ICE with -O1 -ftree-loop-linear on small test case Because the submitted patch has not yet been approved and applied. On Fri, 17 Dec 2004, fjahanian at apple dot com wrote: --- Additional Comments From fjahanian at apple dot com 2004-12-17 19:40 --- Why hasn't been there be a resolution of this PR? It seems that all issues, including elimination of loop numbers, etc. have been taken care of. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18792
[Bug target/19061] IA64 GCC pointer confusion results in optimization error
-- What|Removed |Added GCC host triplet||ia64-hp-hpux11.23 Summary|ia64-hp-hpux11.23 |IA64 GCC pointer confusion ||results in optimization ||error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
[Bug tree-optimization/19062] New: -Wuninitialized tricked by conditional assignments
With the fix for PR 18501 we are now emitting false positives on gcc.dg/uninit-5.c and gcc.dg/uninit-9.c. Analysis of problem: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01309.html -- Summary: -Wuninitialized tricked by conditional assignments Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: dnovillo at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/18501] [4.0 Regression] Missing 'used unintialized' warning
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-17 22:21 --- Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01314.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 22:41 --- Isn't this just a dup of the long standing bug 5035? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From dnovillo at redhat dot com 2004-12-17 22:54 --- Subject: Re: -Wuninitialized tricked by conditional assignments pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 22:41 --- Isn't this just a dup of the long standing bug 5035? Indeed. I must've searched for the wrong string. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug tree-optimization/19062] -Wuninitialized tricked by conditional assignments
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:12 --- So closing as a dup then. *** This bug has been marked as a duplicate of 5035 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:13 --- *** Bug 19062 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug c++/19063] New: [3.4/4.0 regresion] ICE on invalid template parameter
The following testcase causes an ICE since gcc 3.4.0:
===
templateoperator struct A {};
===
PR13268B.cc:5: error: expected identifier before 'operator'
PR13268B.cc:5: error: declaration of 'operator' as non-function
PR13268B.cc:5: internal compiler error: tree check: expected class
'declaration', have 'type' (void_type) in process_template_parm, at cp/pt.c:2318
Please submit a full bug report, [etc.]
The bug is similar to PR13268 in that grokdeclarator returns values that
the caller cannot handle gracefully.
But in this case we actually have a regression.
Btw, if an error occurs, grokdeclarator might be returning 0 (which should
probably be NULL_TREE), error_mark_node (which is not documented) or
void_type_node (even if the caller expects a declaration as in this bug)
or ...
Is this intended, or is some heavy cleanup required?
--
Summary: [3.4/4.0 regresion] ICE on invalid template parameter
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19063
[Bug c++/19063] [3.4/4.0 regresion] ICE on invalid template parameter
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:20 --- : Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160). Confirmed. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-17 23:20:38 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19063
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 23:25 --- : Search converges between 2004-11-25-014001-trunk (#656) and 2004-11-25-161001-trunk (#657). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From belyshev at lubercy dot com 2004-12-17 23:28 --- We expanding this: ___r2.303 = MAX_EXPR ___r3.316, *((int *) ___r2.303 + 1B); into this: (insn 12778 12777 12779 1127 (set (reg/v:SI 1280 [ ___r2.303 ]) (reg/v:SI 1273 [ ___r3.316 ])) -1 (nil) (nil)) (insn 12779 12778 12780 1127 (set (reg:CCGC 17 flags) (compare:CCGC (reg/v:SI 1280 [ ___r2.303 ]) (mem:SI (plus:SI (reg/v:SI 1280 [ ___r2.303 ]) (const_int 1 [0x1])) [0 S4 A32]))) -1 (nil) (nil)) ... which is wrong. So the problem is with expander, unless i am mistaken. -- What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Additional Comments From giovannibajo at libero dot it 2004-12-17 23:35 --- Some discussion about how this warning interacts with the tree-ssa framework can be found here: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01309.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From giovannibajo at libero dot it 2004-12-17 23:48 --- Yes, that's the problem. The whole point is that the parser does not have enough context information to fully check for the number of template headers: there is an off-by-one possible error it has to allow. For instance: template void Aint::foo(void); The correctness of this depends on whether Aint uses an explicit specialization or not. So yes, we could unify this for 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:50 ---
(In reply to comment #3)
We expanding this:
Yes it is, here is an small example of where we produce wrong code, I have to
think of a full working
testcase which we can run:
int *fff;
int f(int a, int b)
{
int crcc = b;
int d = *((int*)(a+1));
int i;
a = d = b? d:b;
for(i=0;ia;i++)
fff[i] = a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
