[Bug c/29159] forgotten memcpy and memset with -fwhole-program --combine
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 06:03 --- related to PR 24729 and another PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29159
[Bug middle-end/17402] static functions are removed before builtins are expanded
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-21 06:05 --- *** Bug 29159 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||acahalan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17402
[Bug c/29159] forgotten memcpy and memset with -fwhole-program --combine
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 06:05 --- Actually this is a dup of bug 17402. -fwhole-program causes memcpy/memset to become static. *** This bug has been marked as a duplicate of 17402 *** -- 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=29159
[Bug middle-end/17402] static functions are removed before builtins are expanded
--- Comment #9 from acahalan at gmail dot com 2006-09-21 06:18 --- Regarding comment #3, why is -fwhole-program accepted without -ffreestanding? Unlike the original poster (who wrote I don't care about this anymore.), this is a rather annoying bug for me. I'll check again tomorrow, but I recall that something else broke with -ffreestanding. I really don't think it is right to close out a bug as a dupe against one which the original reporter has lost all interest in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17402
[Bug middle-end/29160] New: missed optimization: redundant casts prevent vectorization
Details in this thread:
http://gcc.gnu.org/ml/gcc/2006-09/msg00167.html
A silly little testcase which the vectorizer doesn't vectorize:
unsigned char qa[128];
unsigned char qb[128];
unsigned char qc[128];
unsigned char qd[128];
void autovectqi (void)
{
int i;
for (i = 0; i 128; i ++)
qd[i] = qa[i] ^ qb[i] + qc[i];
}
...
If I change 'qb[i] + qc[i]' to e.g. 'qb[i] qc[i]' the vectorizer works
fine.
autovecttest.c:11: note: not vectorized: relevant stmt not supported: D.1861_9
= (signed char) D.1860_8
Devnag suggested the solution should be part of a tree-combin pass:
http://gcc.gnu.org/ml/gcc/2006-09/msg00182.html
Dorit suggested to add it as part of the vectorizer's pattern-recognition
engine:
http://gcc.gnu.org/ml/gcc/2006-09/msg00281.html
--
Summary: missed optimization: redundant casts prevent
vectorization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29160
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-09-21 08:21 --- Subject: Re: [ecj] update build instructions to account for changes This is found using the normal gcc specs approach. In a distribution I'd expect ecj1 to end up in the gcc-lib dir. In my case I just have it on my PATH. We won't be including the ecj sources in the gcc tree. As I recall that was rejected by the SC. So it will always be a separate download. The best thing would be if I could just sudo apt-get install ecj. If there are any differences between ecj and ecj1, we should provide some kind of wrapper. A nice possibility, would be to support dropping the downloaded JAR somewhere in the tree where it installs correctly and automagically. This would not be against the SC decision. Both ecj and the new gcjh can be run on any vm, including all the free ones. I've built libgcj many times running these purely interpreted and it is not painfully slow. Cool, though not unexpected because the code generation of Java bytecodes is not that hard (apart from the unreachable and uninitialized code checking). Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug middle-end/29160] missed optimization: redundant casts prevent vectorization
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-21 08:51 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-09-21 08:51:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29160
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-09-21 09:00 --- I like this solution a lot. NICE! It seems as if everything is now consistent except for std::string. Any thoughts on that one? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug c/29154] [4.0/4.1/4.2 Regression] *(* ppointer++)++ = *pointer++ generates bad code
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-21 09:12 ---
Confirmed. Gimplification get's this wrong. Testcase:
extern void abort (void);
void foo(int **p, int *q)
{
*(*p++)++ = *q++;
}
int main()
{
int i = 42, j = 0;
int *p = i;
foo(p, j);
if (p - 1 != i
|| j != 0
|| i != 0)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, rakdver at gcc dot gnu
||dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.0.3 4.1.1 4.2.0
Known to work||3.4.6
Last reconfirmed|-00-00 00:00:00 |2006-09-21 09:12:02
date||
Summary|*(* ppointer++)++ = |[4.0/4.1/4.2 Regression] *(*
|*pointer++ generates bad|ppointer++)++ = *pointer++
|code|generates bad code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29154
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #14 from pcarlini at suse dot de 2006-09-21 09:13 --- (In reply to comment #13) I like this solution a lot. NICE! It seems as if everything is now consistent except for std::string. Any thoughts on that one? basic_string is delicate, from many different points of view, as we know well, and, at minimum, the current design cannot use the entire the full allocator' max_size. Let's not fiddle with it. I will think about ext/vstring... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-09-21 10:21 --- Ok, seems sane enough. Just curious about the omission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #16 from pcarlini at suse dot de 2006-09-21 10:22 --- (In reply to comment #15) Ok, seems sane enough. Just curious about the omission. I'm going to adjust vstring first. Hopefully we can back port something to basic_string, but really seems tricky (_S_max_size is static, exported, blah...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #17 from paolo at gcc dot gnu dot org 2006-09-21 10:34 --- Subject: Bug 29134 Author: paolo Date: Thu Sep 21 10:34:48 2006 New Revision: 117109 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117109 Log: 2006-09-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29134 (ext/vstring bits) * include/ext/sso_string_base.h (__sso_string_base::_S_max_size): Remove. (__sso_string_base::_M_max_size): Use allocator' max_size. (__sso_string_base::_M_create): Adjust. * include/ext/vstring.h: Minor comment tweak. * testsuite/ext/vstring/capacity/29134.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/vstring/capacity/ trunk/libstdc++-v3/testsuite/ext/vstring/capacity/29134.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/sso_string_base.h trunk/libstdc++-v3/include/ext/vstring.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug c++/29163] New: Overloaded operator delete[] doesn't get called
Hi,
recently I wrote the tiny program attached below to test overloading of new and
delete. Unfortunately, the overloaded delete[] operator does not get called.
:-(
System: Linux HOSTNAME 2.6.17-1.2187_FC5 #1 SMP Mon Sep 11 01:16:59 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux
g++: g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
g++32 (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5)
=
#include iostream
using namespace std;
class myclass {
public:
static void * operator new (std::size_t size) throw() {
cout myclass new operator\n;
return NULL;
}
static void * operator new[] (std::size_t size) throw() {
cout myclass new[] operator\n;
return NULL;
}
static void operator delete (void *p) throw() {
cout myclass delete operator\n;
}
static void operator delete[] (void *p) throw() {
cout myclass delete[] operator\n;
}
};
int main() {
myclass *ad;
ad = new myclass;
ad = new myclass[10];
delete[] ad;
delete ad;
return 0;
}
=
--
Summary: Overloaded operator delete[] doesn't get called
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Andreas dot Kowarz at tu-dresden dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29163
[Bug c++/29164] New: Overloaded operator delete[] doesn't get called
Hi,
recently I wrote the tiny program attached below to test overloading of new and
delete. Unfortunately, the overloaded delete[] operator does not get called.
:-(
System: Linux HOSTNAME 2.6.17-1.2187_FC5 #1 SMP Mon Sep 11 01:16:59 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux
g++: g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
g++32 (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5)
Regards,
Andreas Kowarz
=
#include iostream
using namespace std;
class myclass {
public:
static void * operator new (std::size_t size) throw() {
cout myclass new operator\n;
return NULL;
}
static void * operator new[] (std::size_t size) throw() {
cout myclass new[] operator\n;
return NULL;
}
static void operator delete (void *p) throw() {
cout myclass delete operator\n;
}
static void operator delete[] (void *p) throw() {
cout myclass delete[] operator\n;
}
};
int main() {
myclass *ad;
ad = new myclass;
ad = new myclass[10];
delete[] ad;
delete ad;
return 0;
}
=
Output:
myclass new operator
myclass new[] operator
myclass delete operator
--
Summary: Overloaded operator delete[] doesn't get called
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Andreas dot Kowarz at tu-dresden dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug c++/29163] Overloaded operator delete[] doesn't get called
--- Comment #1 from Andreas dot Kowarz at tu-dresden dot de 2006-09-21 10:47 --- *** This bug has been marked as a duplicate of 29164 *** -- Andreas dot Kowarz at tu-dresden dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29163
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #1 from Andreas dot Kowarz at tu-dresden dot de 2006-09-21 10:47 --- *** Bug 29163 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-21 11:25 --- EDG ends up not even calling the overloaded delete. Looking at the std I can see no reason why your program should not use the overloaded deletes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #3 from Andreas dot Kowarz at tu-dresden dot de 2006-09-21 11:59 --- (In reply to comment #2) EDG ends up not even calling the overloaded delete. Looking at the std I can see no reason why your program should not use the overloaded deletes. For the moment, I can work around the bug by calling the operator directly, e.g. myclass::operator delete[] (ad)--- (in form of a preprocessor macro). Seems, I should provide macros for all of the four operators since my source code is intended to be compiled with other compilers, too. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation with structs due to new struct alias
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-09-21 12:15 --- Subject: Re: [4.2 Regression] Misscompilation with structs due to new struct alias On 21 Sep 2006 04:23:24 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-21 04:23 --- may_alias_p returns true for: (gdb) p debug_generic_expr (ptr) xaD.1527 (gdb) p debug_generic_expr (var) SMT.5D.1548 (In reply to comment #2) So, actually, i'm pretty sure they should have the same SMT, because they should be in the same alias set. They are not the exact same aliasing set but conflicting ones. actually, they aren't just conflicting, one is a complete subset of another. Why do they get different SMT's? Because of this: /* To avoid creating unnecessary memory tags, only create one memory tag per alias set class. Note that it may be tempting to group memory tags based on conflicting alias sets instead of equivalence. That would be wrong because alias sets are not necessarily transitive (as demonstrated by the libstdc++ test 23_containers/vector/cons/4.cc). Given three alias sets A, B, C such that conflicts (A, B) == true and conflicts (A, C) == true, it does not necessarily follow that conflicts (B, C) == true. */ Yeah, but then you run into the situation we have here where there are no real variables to hold these two sets together. In other words, this won't work if you have no addressable variables in your function that could conflict with both. Diego, pruning isn't doing anything wrong here. One thing that would work properly is to create fake non-local variables for each parameter's pointed to type. Then one of the SMT's will end up with both parameter symbols in it's alias sets, and everything will work. Otherwise, there are no addressable variables that will cause these two sets to be believed to be the same. I will implement this solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #11 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21 12:18 --- Subject: RE: Found a problem with the JNI methods declared and implemented It is the only solution I found. The problem does not exist with Solaris 10 ! William Paul Philibert Administrateur UNIX et SAN [EMAIL PROTECTED] Hébergement Telus Corporation Inc. (418) 722-1280 -Message d'origine- De : jblaine at mitre dot org [mailto:[EMAIL PROTECTED] Envoyé : 20 septembre 2006 22:25 À : William-Paul Philibert Objet : [Bug libgcj/27823] Found a problem with the JNI methods declared and implemented --- Comment #10 from jblaine at mitre dot org 2006-09-21 02:24 --- Subject: Re: New: Found a problem with the JNI methods declared and implemented Found this thread in the bug mailing list archives. I have the same problem :( Is there a fix more specific than disable that test so I can proceed? Details? Does that mean just comment out the call to check_jni_methods.sh in ...Makefile? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation with structs due to new struct alias
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-09-21 12:22 ---
Subject: Re: [4.2 Regression] Misscompilation with structs due to new struct
alias
Why do they get different SMT's?
Because of this:
/* To avoid creating unnecessary memory tags, only create one memory tag
per alias set class. Note that it may be tempting to group
memory tags based on conflicting alias sets instead of
equivalence.
That would be wrong because alias sets are not
necessarily transitive (as demonstrated by the libstdc++ test
23_containers/vector/cons/4.cc). Given three alias sets A, B, C
such that conflicts (A, B) == true and conflicts (A, C) == true,
it does not necessarily follow that conflicts (B, C) == true. */
Yeah, but then you run into the situation we have here where there are
no real variables to hold these two sets together. In other words,
this won't work if you have no addressable variables in your function
that could conflict with both.
Diego, pruning isn't doing anything wrong here.
One thing that would work properly is to create fake non-local
variables for each parameter's pointed to type. Then one of the SMT's
will end up with both parameter symbols in it's alias sets, and
everything will work.
Otherwise, there are no addressable variables that will cause these
two sets to be believed to be the same.
it is probably not enough to consider just types of the parameters.
I wrote the testcase this way since it is simpler, but it should fail
exactly the same way with
struct test1 *out_of_nowhere_1 (void);
struct test2 *out_of_nowhere_2 (void);
int bla(void)
{
struct test1 *xa = out_of_nowhere_1 ();
struct test2 *xb = out_of_nowhere_2 ();
global = 1;
xb-sub.a = 1;
xa-a = 8;
return xb-sub.a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug c/29129] [4.2 Regression] [DR needed] unnamed parameters using [*]
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-09-21 12:30 --- Suspending pending DR. Neil's interpretation would be a more useful sense of the standard, but there is a deliberate decision to err on the side of rejecting code rather than of accidentally creating an extension. If the WG14 Spring 2007 meeting does happen in the UK as proposed then I may try to prepare DRs for this and other issues. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED Summary|[4.2 Regression] Strictly |[4.2 Regression] [DR needed] |conforming code rejected|unnamed parameters using [*] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2006-09-21 13:03 --- Proposed patches are posted at... http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00906.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00908.html ...which together should allow this PR to be finally closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-21 13:07 --- We have a flag (TREE_THIS_NOTRAP) to annotate ARRAY_REFs and INDIRECT_REFs. It could be used to guide tree-ifcvt to do the transformation. Can we have if-converted stores at the tree level at all? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug c++/29165] New: dependent name resolution finds static functions
Under the current standard, the following program should not compile:
static void f(int) {}
template class T void t(T t) { f(t); }
void g() { t(1); }
EDG 3.0 rejects it.
The C++ standard clause 14.6.4.2 states that function calls depending on
template parameters may only consider function declarations with external
linkage.
I have no doubt this is a bug, but I'm not sure whether anybody should bother
fixing it or not, because issue 561 may change this situation:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#561
--
Summary: dependent name resolution finds static functions
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29165
[Bug middle-end/29166] New: broken unwind information for many life variables resulting in register corruption
Attached is a testcase which shows that some registers are clobbered over throwing/catching an exception: bashc++ unwind_test.cpp bash./a.out Checksum not OK ( 42895 != 58377 ). Register corruption in stack unwinding. In the debugger you can see, that the fixed integer registers r4-r7 are not reset correctly during stack unwinding. The value of the callee-saved registers r4-r7 differ before and after the call to test() from main(). This error was reported against gcc-3.3.3 but still happens with gcc 4.1. -- Summary: broken unwind information for many life variables resulting in register corruption Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: EH Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: ia64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug middle-end/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #1 from matz at gcc dot gnu dot org 2006-09-21 13:35 --- Created an attachment (id=12303) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12303action=view) Breaking testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug middle-end/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #2 from matz at gcc dot gnu dot org 2006-09-21 13:39 ---
Some more analysis of the original bugreport (
https://bugzilla.novell.com/show_bug.cgi?id=201157 ) :
For gcc version 4.1.2 20060731 (prerelease) (SUSE Linux),
r4-r7 contain before the call:
86, 87, 88, 89
and after the call:
87, 88, 89, 4611686018427403552
(gdb) p/x $r7
$2 = 0x40003d20
(gdb) info symbol $r7
test() + 64 in section .text
(gdb) b *$r7
Breakpoint 4 at 0x40003d20: file unw.cc, line 85.
(gdb) l 85
80 }
81
82 void test()
83 {
84 try {
85 doIt();
86 } catch( Ex ) { }
87 }
88
89 int main(char** argv, int argc)
The address in r7 is the return address of the call. I googled a bit for
unwind ia64 r4 and found e.g. this:
http://www.gelato.unsw.edu.au/archives/linux-ia64/0506/14430.html
This is a patch for the kernel, but it's about using some wrong code
in it's own unwinder leading to clobber r4-7, so perhaps similar code is
used in libunwind?
Looks like the unwind information is broken, the addresses for the register
contents for r4-r7 is off-by-8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug middle-end/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #3 from matz at gcc dot gnu dot org 2006-09-21 13:40 --- Hmpf. I wonder if there's any tool to really inspect the unwind info, like it is possible for dwarf. But readelf doesn't help very much: % readelf -wf a.out nothing, no wonder, it's no dwarf % readelf -u a.out ... _Z4doItv: [0x4b00-0x40003ce0], info at +0x87b0 v1, flags=0x0 (), len=40 bytes R2:prologue_gr(mask=[psp],grsave=r119,rlen=49) P5:frgr_mem(grmask=[r4,r5,r6,r7],frmask=[f2,f3,f4,f5,f16,f17,f18,f19,f20,f21,f22,f23,f24,f25,f26,f27,f28,f29,f30,f31]) P4:spill_mask(imask=[---,---,---,---,rr-,rr-,-f-,ff-,ff-,ff-,ff-,ff-,ff-,ff-,ff-,ff-,f]) P7:mem_stack_v(t=3) P7:unat_when(t=7) P7:unat_psprel(pspoff=0x10-0x180) P7:pfs_when(t=9) P7:pfs_psprel(pspoff=0x10-0x178) P7:rp_when(t=18) P7:rp_psprel(pspoff=0x10-0x148) R3:body(rlen=2345) R1:prologue(rlen=0) R1:prologue(rlen=0) _Z4testv: [0x40003ce0-0x40003db0], info at +0x87e0 v1, flags=0x3 ( ehandler uhandler), len=16 bytes R2:prologue_gr(mask=[rp,ar.pfs,psp],grsave=r32,rlen=5) P7:pfs_when(t=0) P7:mem_stack_v(t=1) P7:rp_when(t=4) R3:body(rlen=34) B2:epilogue(t=2,ecount=0) R1:prologue(rlen=0) R1:prologue(rlen=0) R1:prologue(rlen=0) I traced the things in libunwind a bit, and know that the one writing the wrong location of R4-7 into context-loc is the IA64_INSN_ADD_PSP_NAT unwind script instruction, interpreted in _ULia64_find_save_locs (in run_script actually). And it happens while context still is set to the doIt() function. But I have no idea, how that script is generated, or how it relates to the assembler file. For instance, the start of doIt() has this code: .save.g 0x1 .mem.offset 344, 0 // st8.spill [r18] = r4, 16//, ;; .save.g 0x2 .mem.offset 336, 0 // st8.spill [r17] = r5, 16//, .save.g 0x4 .mem.offset 328, 0 // st8.spill [r18] = r6, 16//, ;; .save.g 0x8 .mem.offset 320, 0 // st8.spill [r17] = r7, 16//, I assume (because there are no explicit unwind sections in the assembler source) that these .save.g and .mem.offset somehow are pseudo instructions which somehow produce unwind info. But I'm at a loss here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug tree-optimization/25737] [4.1/4.2 Regression] ACATS c974001 c974013 hang with struct aliasing
--- Comment #30 from krebbel at gcc dot gnu dot org 2006-09-21 13:56 --- All three (c974001, c974013 and cb20001) do not fail on s390x anymore since my patch removing the CLOBBERs for eh registers has been applied: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00498.html If the analysis in this PR is correct it seems unlikely to me that the patch is directly related to the cause of the problem. Maybe it simply hides the real problem somehow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug tree-optimization/25737] [4.1/4.2 Regression] ACATS c974001 c974013 hang with struct aliasing
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-09-21 13:59
---
Note that Ada requires a patch to enable struct-aliasing, as it does
bool
gnat_post_options (const char **pfilename ATTRIBUTE_UNUSED)
{
flag_inline_trees = 1;
if (!flag_no_inline)
flag_no_inline = 1;
if (flag_inline_functions)
flag_inline_trees = 2;
flag_tree_salias = 0;
return false;
}
at the moment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
2 bugs in mt_allocator (tested on gcc 4.1.1)
Hi!
This example will demonstrate 2 problems in mt_allocator.cc:
typedef __gnu_cxx::__mt_allocchar allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 4, 8, (5 - 4 * sizeof(void*)), 4096, 10,
false);
mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(4);
First bug in __pool..::_M_initialize():
Binmap_type __bin_max = _M_options._M_min_bin; // not correct.
size_t __bin_max = _M_options._M_min_bin; // correct.
Second bug in __pool..::_M_reserve_block():
while (--__block_count 0) // not correct because __block_count may be
equal 0(and size_t is unsigned)
{
__c += __bin_size;
__block-_M_next = reinterpret_cast_Block_record*(__c);
__block = __block-_M_next;
}
while (__block_count 0) // correct
{
__c += __bin_size;
__block-_M_next = reinterpret_cast_Block_record*(__c);
__block = __block-_M_next;
--__block_count;
}
Best regards, dk.
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2006-09-21 14:05 --- Note that Ada requires a patch to enable struct-aliasing, as it does Right, there is some confusion in this PR. The problem does *not* exist with the pristine mainline sources so I'm reclassifying. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Summary|[4.1/4.2 Regression] ACATS |ACATS c974001 c974013 hang |c974001 c974013 hang with |with struct aliasing |struct aliasing | Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #12 from jblaine at mitre dot org 2006-09-21 14:09 --- FWIW, this fails for me in the exact same way under Red Hat Enterprise Linux v3. Both of my 4.1.1 builds are complete failures at this point (the other being Solaris 9 mentioned above, and yeah I used CONFIG_SHELL=/bin/ksh there) -- jblaine at mitre dot org changed: What|Removed |Added CC||jblaine at mitre dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #13 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21 14:20 --- Subject: RE: Found a problem with the JNI methods declared and implemented Just in case, are you building outside the source directory!? setenv CONFIG_SHELL /bin/ksh mkdir /usr/local/build-gcc-4.1.1 cd /usr/local/build-gcc-4.1.1 /usr/local/gcc-4.1.1/configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as --prefix=/usr/local --with-libiconv-prefix=/usr/local Those are working fine in Solaris 10 William Paul Philibert -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #14 from jblaine at mitre dot org 2006-09-21 14:22 --- I'm building in a 'foo' directory I made at the top of the unpackaged source tree. mkdir foo cd foo ../configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-21 14:31 --- mkdir foo cd foo ../configure Beginner error I'm afraid. :-) See http://gcc.gnu.org/install/configure.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug c++/29165] dependent name resolution finds static functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 14:37 --- *** This bug has been marked as a duplicate of 19092 *** -- 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=29165
[Bug c++/19092] [DR 561] template code does not ignore static functions overloads
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-21 14:37 --- *** Bug 29165 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||andrew dot stubbs at st dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug c++/19092] [DR 561] template code does not ignore static functions overloads
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-21 14:37 --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#561 Suspending since that Defect Report is still open. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #16 from lucier at math dot purdue dot edu 2006-09-21 14:38 --- Subject: Re: Found a problem with the JNI methods declared and implemented On Sep 21, 2006, at 10:31 AM, ebotcazou at gcc dot gnu dot org wrote: mkdir foo cd foo ../configure Beginner error I'm afraid. :-) See http://gcc.gnu.org/install/ configure.html Eric, it is not forbidden to put objdir into srcdir. It is not unsupported to do so. Among the many bugs I've found in gcc build and configuration over the years, not one was due to this. More and more bug reports are met with comments like it works for me (IWFM), which I don't find helpful. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug c++/29168] New: ICE in volatile member function when calling static member
The following code triggers an ICE in gcc 4.1.0 and 4.1.1
===
struct MyClass
{
MyClass( const MyClass );
MyClass operator=( const MyClass );
void volatile_member_func() volatile;
static void static_func() {};
};
void
MyClass::volatile_member_func() volatile
{
static_func();
}
===
this code compiles correctly under 3.3
compiler command line and output:
% g++ ICE.cpp
ICE.cpp: In member function void MyClass::volatile_member_func() volatile:
ICE.cpp:12: internal compiler error: in cp_expr_size, at
cp/cp-objcp-common.c:101
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
compiler version:
% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc4.1.1
Thread model: posix
gcc version 4.1.1
system info:
% uname -a
Linux aces04 2.6.16.21-0.15-smp #1 SMP Tue Jul 25 15:28:49 UTC 2006 x86_64
x86_64 x86_64 GNU/Linux
--
Summary: ICE in volatile member function when calling static
member
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ed dot Ralston at jhuapl dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29168
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #33 from krebbel at gcc dot gnu dot org 2006-09-21 14:49 --- Ok. I wasn't aware of this. On s390 these testcases failed even without the struct-aliasing patch. So obviously it was just a coincidence that the same testcases failed on s390 (plus one more). Sorry if I made the confusion complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #17 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21 14:49 --- Subject: RE: Found a problem with the JNI methods declared and implemented Well the only way I had to compile GCC 4.1.1 under Solaris 9 and get rid of the JNI methods error was to disable the test right in the source. William Paul Philibert -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #34 from dberlin at gcc dot gnu dot org 2006-09-21 14:53 --- Subject: Re: ACATS c974001 c974013 hang with struct aliasing On 21 Sep 2006 14:49:14 -, krebbel at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #33 from krebbel at gcc dot gnu dot org 2006-09-21 14:49 --- Ok. I wasn't aware of this. On s390 these testcases failed even without the struct-aliasing patch. So obviously it was just a coincidence that the same testcases failed on s390 (plus one more). Sorry if I made the confusion complete. It's okay, since this bug will never be fixed until someone can explain why they believe making things non-addressable will result in more aliasing, and not less. I suspect the reality is there is some fundamental misunderstanding of how aliasing or addressability works on the part of the Ada folks (no offense to them, it's just the arguments they keep offering are, well, strange to anyone who understands aliasing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug c++/29168] ICE in volatile member function when calling static member
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 14:54 --- *** This bug has been marked as a duplicate of 26577 *** -- 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=29168
[Bug c++/26577] [4.0/4.1 regression] ICE in cp_expr_size with volatile and non POD
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-09-21 14:54 --- *** Bug 29168 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Ed dot Ralston at jhuapl dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #26 from eweddington at cso dot atmel dot com 2006-09-21 15:18 --- (From update of attachment 12162) The gcc-4.1.1-dwarf32-note.patch file is obsolete and no longer needed. Torleif was able to build a parser to work with both size DWARF addresses. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Attachment #12162|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #18 from jblaine at mitre dot org 2006-09-21 16:04 --- Not beginner error. I just tried with my objdir completely outside the srcdir and the error is the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-09-21 16:09 --- Eric, it is not forbidden to put objdir into srcdir. It is not unsupported to do so. Simply amazing... Quoting http://gcc.gnu.org/install/configure.html: First, we highly recommend that GCC be built into a separate directory than the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported. Among the many bugs I've found in gcc build and configuration over the years, not one was due to this. It may have been the hidden trigger of a bunch of them... More and more bug reports are met with comments like it works for me (IWFM), which I don't find helpful. It's actually IWIYFTI (It Works If You Follow The Instructions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #20 from lucier at math dot purdue dot edu 2006-09-21 16:22 --- Subject: Re: Found a problem with the JNI methods declared and implemented On Sep 21, 2006, at 12:09 PM, ebotcazou at gcc dot gnu dot org wrote: building where objdir is a subdirectory of srcdir is unsupported. I've followed the mail lists for years while this was debated; I don't think it's settled. (./configure; make definitely isn't supported.) Among the many bugs I've found in gcc build and configuration over the years, not one was due to this. It may have been the hidden trigger of a bunch of them... Ah, yes, the latent bug syndrome. If you find it, it's your problem ... More and more bug reports are met with comments like it works for me (IWFM), which I don't find helpful. It's actually IWIYFTI (It Works If You Follow The Instructions). More actually it's If I can find a way to criticize your bug report, I don't have to look for root causes. This is a real bug. See the message a few lines up. I'm not saying it's *your* bug, but it's real. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug c/29169] New: sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10 I get the following when bootstrapping mainline on i386-pc-solaris2.10: Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20060921/gcc/xgcc -B/u01/var/tmp/gcc_trunk_svn/gcc_20060921/gcc/ /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/sse3-not-fisttp.c -O -march=nocona -mno-sse3 -fno-show-column -S -o sse3-not-fisttp.s(timeout = 300) PASS: gcc.target/i386/sse3-not-fisttp.c (test for excess errors) FAIL: gcc.target/i386/sse3-not-fisttp.c scan-assembler-not fisttp Is this test supposed to PASS on Solaris 10 x86? Brett Albertson -- Summary: sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2006-09-21 16:53 --- I suspect the reality is there is some fundamental misunderstanding of how aliasing or addressability works on the part of the Ada folks (no offense to them, it's just the arguments they keep offering are, well, strange to anyone who understands aliasing). I suspect that we were simply not on the same page, you being at a general level about aliasing/addressability and I being at the implementation level about DECL_NONADDRESSABLE_P and TYPE_NONALIASED_COMPONENT. As I told Richard in Ottawa, I plan to revisit this for 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #21 from tromey at gcc dot gnu dot org 2006-09-21 17:02 --- I think the best solution is to disable the check. We don't need it and making it always be correct seems like a pain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug c/29170] New: autovectorizer converts signed types to unsigned, then can't match patterns
I have a simple reduction test. (attachment to follow) I'm compiling it with: ../ppc_build/gcc/cc1 -mcpu=G4 -maltivec -O3 -ftree-vectorize reductest.c If the types are all unsigned, the loop is vectorized. If the types are all signed, the vectorizer bails because it doesn't know some pattern and there are suspicious unsigned types in the log: reductest.c:8: note: Detected induction. reductest.c:8: note: === vect_mark_stmts_to_be_vectorized === reductest.c:8: note: init: phi relevant? ivtmp.30_19 = PHI ivtmp.30_18(2), 512(0); reductest.c:8: note: init: phi relevant? sum_22 = PHI sum_13(2), 0(0); reductest.c:8: note: init: phi relevant? i_21 = PHI i_15(2), 0(0); reductest.c:8: note: init: phi relevant? a_20 = PHI a_14(2), a_6(0); reductest.c:8: note: init: stmt relevant? L0: reductest.c:8: note: init: stmt relevant? D.1686_9 = *a_20 reductest.c:8: note: init: stmt relevant? D.1687_10 = (short unsigned int) D.1686_9 reductest.c:8: note: init: stmt relevant? sum.0_11 = (short unsigned int) sum_22 reductest.c:8: note: init: stmt relevant? D.1689_12 = D.1687_10 + sum.0_11 reductest.c:8: note: init: stmt relevant? sum_13 = (short int) D.1689_12 reductest.c:8: note: vec_stmt_relevant_p: used out of loop. reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: init: stmt relevant? a_14 = a_20 + 2B reductest.c:8: note: init: stmt relevant? i_15 = i_21 + 1 reductest.c:8: note: init: stmt relevant? ivtmp.30_18 = ivtmp.30_19 - 1 reductest.c:8: note: init: stmt relevant? if (ivtmp.30_18 != 0) goto L6; else goto L2; reductest.c:8: note: init: stmt relevant? L6: reductest.c:8: note: worklist: examine stmt: sum_13 = (short int) D.1689_12 reductest.c:8: note: vect_is_simple_use: operand D.1689_12 reductest.c:8: note: def_stmt: D.1689_12 = D.1687_10 + sum.0_11 reductest.c:8: note: type of def: 2. reductest.c:8: note: worklist: examine use 2: D.1689_12 reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: worklist: examine stmt: D.1689_12 = D.1687_10 + sum.0_11 reductest.c:8: note: vect_is_simple_use: operand D.1687_10 reductest.c:8: note: def_stmt: D.1687_10 = (short unsigned int) D.1686_9 reductest.c:8: note: type of def: 2. reductest.c:8: note: worklist: examine use 2: D.1687_10 reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: vect_is_simple_use: operand sum.0_11 reductest.c:8: note: def_stmt: sum.0_11 = (short unsigned int) sum_22 reductest.c:8: note: type of def: 2. reductest.c:8: note: worklist: examine use 2: sum.0_11 reductest.c:8: note: mark relevant 0, live 1. reductest.c:8: note: worklist: examine stmt: sum.0_11 = (short unsigned int) sum_22 reductest.c:8: note: vect_is_simple_use: operand sum_22 reductest.c:8: note: def_stmt: sum_22 = PHI sum_13(2), 0(0); reductest.c:8: note: Unsupported pattern. reductest.c:8: note: not vectorized: unsupported use in stmt. reductest.c:8: note: unexpected pattern. reductest.c:8: note: vectorized 0 loops in function. I have not yet checked out the 4.1 tip or mainline to try this there... -- Summary: autovectorizer converts signed types to unsigned, then can't match patterns Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eplondke at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: powerpc-linux and others http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
[Bug tree-optimization/29170] autovectorizer converts signed types to unsigned, then can't match patterns
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
[Bug tree-optimization/29170] autovectorizer converts signed types to unsigned, then can't match patterns
--- Comment #1 from eplondke at gmail dot com 2006-09-21 17:05 --- Created an attachment (id=12304) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12304action=view) Test to try signed/unsigned reductions A simple reduction test. Change WHATSIGN between signed and unsigned to try different signedness. unsigned seems to work, signed fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-21 17:07 --- Maybe a --with-installed-ecj-jar=/path option would be good. Then a distro like fedora could build gcj by pointing it at an already-installed ecj; we could install a little sh script in the right place that would run gij properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug tree-optimization/29170] autovectorizer converts signed types to unsigned, then can't match patterns
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 17:09 --- This is a known issue as C standard requires the short to be promoted to an int. This has nothing to do with the autovect except it cannot handle this case yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
[Bug tree-optimization/29170] autovec cannot handle short+=short
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-21 17:11 --- This is a dup of bug 26128. *** This bug has been marked as a duplicate of 26128 *** -- 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=29170
[Bug tree-optimization/26128] Trivial operation not vectorized on char
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 17:11 --- *** Bug 29170 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||eplondke at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26128
[Bug debug/29132] [4.1/4.2 Regression] Mips exception handling broken.
--- Comment #6 from sayle at gcc dot gnu dot org 2006-09-21 17:13 --- Subject: Bug 29132 Author: sayle Date: Thu Sep 21 17:13:33 2006 New Revision: 117114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117114 Log: 2006-09-21 Roger Sayle [EMAIL PROTECTED] PR debug/29132 * dwarf2out.c (dwarf2out_begin_prologue): Initialise the current label, dw_fde_current_label, to be the start of the function, i.e. the same value as dw_fde_begin. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug target/29169] sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
--- Comment #1 from echristo at apple dot com 2006-09-21 17:52 --- Yes, this should pass. -- echristo at apple dot com changed: What|Removed |Added CC|echristo at gcc dot gnu dot | |org | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-21 17:52:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug c/29171] New: forgotten memcpy with -ffreestanding -fwhole-program --combine
Unlike Bug #29159 and Bug #17402, this one involves -ffreestanding. The results
are not really different. Basically, gcc is unable to correctly compile
anything significant with -fwhole-program. With or without the -ffreestanding
option, gcc will leave undefined references to various string.h things. It does
not matter if the program provides these functions in *.c files.
Note that -ffreestanding is illogical. I do have a C library, even including
the various libgcc things. I added -ffreestanding just now because a comment in
Bug #17402 incorrectly suggests this as a fix for the problem. Note that
-ffreestanding is probably undesirable even if would work, because I provide a
runtime and I expect gcc to take advantage of that runtime.
So anyway...
I have a number of *.c files, including a bit of inline assembly, which form
the entire program. (program being a shared object which gets executed via
the _init function) There are no other source libraries. I have a memset.c
containing the obvious function. This is based on klibc (bare-bones Linux C
library) with the assembly files replaced with *.c files.
No matter what attributes I place on the functions, either in the *.c or *.h
files, the compiler produces an undefined reference to memset. Though gcc
certainly compiles the function, it seems to forget this. I don't think an
undefined reference should even be possible with the -fwhole-program option;
this supposedly tells the compiler that I'm giving the WHOLE program.
The gcc version:
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)
The compile command line, with numerous unrelated *.c files
chopped out of the middle:
gcc -m32 -std=gnu99 -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include -D__KLIBC__ -Iinclude
-Iinclude/bits32 -Iinclude/arch/i386 -mregparm=3 -D_REGPARM=3
-Wstrict-prototypes -Wmissing-prototypes -msoft-float -fPIC
-fomit-frame-pointer -march=pentium2 -Os -fno-defer-pop -fno-common
-mtune=nocona -Wstrict-aliasing=2 -fvisibility=hidden -W -Wall -Wshadow -g3
-ffreestanding -fwhole-program --combine -c buffer.c testlib.c klibc/strcmp.c
klibc/strcpy.c klibc/strncpy.c klibc/memcpy.c klibc/memset.c klibc/strlen.c
klibc/strspn.c klibc/strxspn.c klibc/malloc.c klibc/mmap.c klibc/pause.c
klibc/raise.c klibc/sleep.c klibc/sigaction.c klibc/libgcc/__udivdi3.c
klibc/libgcc/__umoddi3.c klibc/libgcc/__udivmoddi4.c -o bigblob.pic
The link command line:
gcc -m32 -shared -Wl,-O9 -Wl,-warn-common -Wl,-soname,libfoo.so.1
-Wl,-z,initfirst -nostartfiles -nodefaultlibs -nostdlib -o tmp.so
bigblob.pic
Examining the result:
nm tmp.so | grep -i ' u '
U memcpy
I have tried the memcpy function with and without various attributes including:
externally_visible, unused, noinline, regparm(0)
Last of all, here is the memcpy function itself.
/
#include string.h
#include stdint.h
void *memcpy(void *restrict dst, const void *restrict src, size_t n)
{
const char *p = src;
char *q = dst;
#if defined(__i386__)
size_t nl = n 2;
asm volatile (cld ; rep ; movsl ; movl %3,%0 ; rep ; movsb:+c (nl),
+S(p), +D(q)
:r(n 3));
#elif defined(__x86_64__)
size_t nq = n 3;
asm volatile (cld ; rep ; movsq ; movl %3,%%ecx ; rep ; movsb:+c
(nq), +S(p), +D(q)
:r((uint32_t) (n 7)));
#else
while (n--) {
*q++ = *p++;
}
#endif
return dst;
}
--
Summary: forgotten memcpy with -ffreestanding -fwhole-program --
combine
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
[Bug middle-end/29171] forgotten memcpy with -ffreestanding -fwhole-program --combine
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 17:57 --- externally_visible should have fixed the undefined symbol. Do you really have a simple testcase instead of just describing what your code does? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-09-21 17:57
---
I've followed the mail lists for years while this was debated; I
don't think it's settled. (./configure; make definitely isn't
supported.)
Tempus fugit. :-)
Index: ChangeLog
===
--- ChangeLog (revision 41976)
+++ ChangeLog (revision 41977)
@@ -1,3 +1,8 @@
+2001-05-12 Dean Wakerley [EMAIL PROTECTED]
+
+ * doc/install.texi: New file. Converted to texinfo from the HTML
+ documentation in wwwdocs/htdocs/install.
41977 gerald First, we @strong{highly} recommend that GCC be built into a
41977 gerald separate directory than the sources which does @strong{not} reside
41977 gerald within the source tree. This is how we generally build GCC;
building
41977 gerald where @emph{srcdir} == @emph{objdir} should still work, but
doesn't
41977 gerald get extensive testing; building where @emph{objdir} is a
subdirectory
41977 gerald of @emph{srcdir} is unsupported.
Ah, yes, the latent bug syndrome. If you find it, it's your problem ...
Correction: if you don't read the doc, ...
More actually it's If I can find a way to criticize your bug report,
We strive to document every single step of the configure and build procedure,
every single bug we run into on exotic platforms and every single workaround
we find. I think it's fair to expect the user to do us the favour of reading
the documentation before reporting a problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug c/29172] New: --combine can't handle #pragma once
The --combine option fails to forget the once property of a header file when gcc moves on to dealing with the next *.c file. The pragma should function just the same as the usual #ifndef _SOME_ARBITRARY_CRAP hack. k 0 $ cat once.h #pragma once #define D k 0 $ cat a.c #include once.h #ifndef D #error No def in a.c! #endif k 0 $ cat b.c #include once.h #ifndef D #error No def in b.c! #endif k 0 $ gcc --combine a.c b.c b.c:3:2: error: #error No def in b.c! k 1 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20060828 (Red Hat 4.1.1-20) k 0 $ -- Summary: --combine can't handle #pragma once Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: acahalan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #9 from bergner at vnet dot ibm dot com 2006-09-21 18:14 --- Created an attachment (id=12305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12305action=view) Patch to rs6000_legitimize_address to force base pointers into rA position of indexed load/store instructions. It seems -msoft-float doesn't like the operand swapping, so this patch disables it when we specify -msoft-float on the compile command. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/29171] forgotten memcpy with -ffreestanding -fwhole-program --combine
--- Comment #2 from acahalan at gmail dot com 2006-09-21 18:15 --- A simple test case would involve the code I gave plus whatever it takes to make gcc decide to call memcpy. What is the most simple thing which triggers that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #10 from bergner at vnet dot ibm dot com 2006-09-21 18:16 --- (From update of attachment 12190) Forgot to obsolete this patch by the updated patch. -- bergner at vnet dot ibm dot com changed: What|Removed |Added Attachment #12190|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #11 from bergner at vnet dot ibm dot com 2006-09-21 18:19 --- Created an attachment (id=12306) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12306action=view) Alternate patch to rs6000_legitimize_address to force base pointers into rA position of indexed load/store instructions. Same as the other patch, except we don't call force_reg() on constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/28861] [4.0/4.1/4.2 regression] ICE on invalid in-class specialization
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-09-21 18:22 --- Subject: Bug 28861 Author: lmillward Date: Thu Sep 21 18:22:11 2006 New Revision: 117117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117117 Log: PR c++/28861 * decl.c (shadow_tag): Return error_mark_node if maybe_process_partial_specialization failed. * g++.dg/template/spec32.C: New test. * g++.dg/parse/crash9.C: Adjust error markers. Added: trunk/gcc/testsuite/g++.dg/template/spec32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash9.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28861
[Bug c++/28861] [4.0/4.1 regression] ICE on invalid in-class specialization
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-09-21 18:26 --- Fixed in 4.2. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE on |on invalid in-class |invalid in-class |specialization |specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28861
[Bug c++/28303] [4.1/4.2 regression] ICE on invalid typedef
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-09-21 18:33 --- Subject: Bug 28303 Author: lmillward Date: Thu Sep 21 18:33:49 2006 New Revision: 117118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117118 Log: PR c++/28303 * decl.c (grokdeclarator): Return error_mark_node on declaration with two or more data types. * g++.dg/template/typedef6.C: New test. * g++.dg/init/error1.C: Adjust error markers. * g++.dg/parse/crash9.C: Likewise. * g++.dg/template/crash55.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/typedef6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/init/error1.C trunk/gcc/testsuite/g++.dg/template/crash55.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28303
[Bug c/29172] --combine can't handle #pragma once
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 18:34 --- I bet the C front-end forgot to tell the preprocessor to rest the pragma once table. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
[Bug c++/28303] [4.1 regression] ICE on invalid typedef
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-09-21 18:34 --- Fixed in 4.2. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE on |[4.1 regression] ICE on |invalid typedef |invalid typedef http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28303
[Bug middle-end/29171] forgotten memcpy with -ffreestanding -fwhole-program --combine
--- Comment #3 from acahalan at gmail dot com 2006-09-21 18:49 ---
foo 0 $ cat foo.c
void *memcpy(void *restrict, const void *restrict, unsigned long);
void *memcpy(void *restrict dst, const void *restrict src, unsigned long n)
{
const char *p = src;
char *q = dst;
while (n--) {
*q++ = *p++;
}
return dst;
}
typedef struct S {
int a[42];
}S;
void __attribute__((used,unused)) _fini(void)
{
S *s1;
S *s2;
__asm__ __volatile__(:=r(s1)::memory);
__asm__ __volatile__(:=r(s2)::memory);
*s1 = *s2;
__asm__ __volatile__(::r(s1):memory);
__asm__ __volatile__(::r(s2):memory);
}
foo 0 $ make
gcc -m32 -std=gnu99 -nostdinc -fPIC -Os -fvisibility=hidden -W -Wall -g3
-ffreestanding -fwhole-program --combine -c foo.c -o bigblob.pic
rm -f tmp.so testcase.so.1.0.1
gcc -m32 -shared -nostartfiles -nodefaultlibs -nostdlib -o tmp.so bigblob.pic
if nm tmp.so | grep -i --color=auto '.* u .*' ; then false ; else true ; fi
U memcpy
make: *** [testcase.so.1.0.1] Error 1
foo 2 $
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
[Bug tree-optimization/29170] autovec cannot handle short+=short
--- Comment #4 from dorit at il dot ibm dot com 2006-09-21 19:30 --- By the way, the testcase gets vectorized if you compile with -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
[Bug other/29173] New: gcc bugzilla help does not describe WAITING
Right now, bug 29171 has status WAITING. I clicked the Status link next to that to see if there is anything I ought to do about it, and I get this page: http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#status The WAITING status does not exist. My bug is in a non-existant status. Well gee. I assume that this means somebody is waiting for more info. On that possibly wrong assumption, I added some more info. Now I don't know what to do. Perhaps I should change the bug to NEW after adding the info? Please update the web page to describe what this value means and what people should do about it. -- Summary: gcc bugzilla help does not describe WAITING Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: acahalan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29173
[Bug middle-end/29174] New: does not recognize memcpy and optimize it
In the code below, gcc fails to optimize a hand-crafted memcpy as a call to the
memcpy function. (or perhaps as rep;movsb when compiling with -Os) I've
tried -O2, -O3, and -Os. There are probably a great number of similar
optimizations that could be done.
This optimization is not unheard of; it is done by Visual Studio 2005. IMHO it
is not really any more insane than autovectorization.
junk 0 $ cat foo.c
void *foo(void *restrict, const void *restrict, unsigned long);
void *foo(void *restrict dst, const void *restrict src, unsigned long n)
{
const char *p = src;
char *q = dst;
while (n--) {
*q++ = *p++;
}
return dst;
}
junk 0 $ gcc -m32 -std=gnu99 -fomit-frame-pointer -Os -S foo.c
junk 0 $ cat foo.s
.file foo.c
.text
.globl foo
.type foo, @function
foo:
pushl %ebx
movl16(%esp), %ebx
movl8(%esp), %ecx
movl12(%esp), %edx
jmp .L2
.L3:
movb-1(%edx), %al
movb%al, -1(%ecx)
.L2:
decl%ebx
incl%ecx
incl%edx
cmpl$-1, %ebx
jne .L3
movl8(%esp), %eax
popl%ebx
ret
.size foo, .-foo
.ident GCC: (GNU) 4.1.1 20060828 (Red Hat 4.1.1-20)
.section.note.GNU-stack,,@progbits
junk 0 $ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)
junk 0 $
--
Summary: does not recognize memcpy and optimize it
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29174
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-09-21 20:24 --- I applied r116954 to 116942. Well, then it's still my patch or patches then. Sorry. It's still using linuxthreads. Also because of the limitations of the ldcw semaphore instruction in PA 1.1, the atomic lock type is 16 bytes and there is a dynamic alignment calculation to select the aligned 4-byte object to use for the ldcw lock. As a result, there are limitations on copying/moving lock objects that aren't present in other implementations. Ah. This is interesting, thanks. One thing you could try, to confirm that this is what's up, is to replace the hppa atomics config with the generic pthreads layer. Probably the best way to do this is to: %mv config/cpu/hppa config/cpu/hppa.dis blow away the build directory, and then rebuild. During the rebuild, you should see this on the configure line: ... configure: CPU config directory is cpu/generic ... checking for thread model used by GCC... posix checking for atomic builtins... no ... To confirm, if you go into the freshly built libstdc++/src directory and ls -al atomicity.cc You should see it pointing to config/cpu/generic/atomicity_mutex/atomicity.h instead of the current config/cpu/hppa/atomicity.h If you try this and run make check-target-libstdc++-v3 and the testresults are fine, then I can try to put in a hack for you that will bypass the current (presumably flawed) hppa atomics config. Or, we can try to fix it to deal with the limitations that are not present on the other linux cpu's. best, -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-21 20:24:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-21 20:24 --- No working test case, no feedback for two months - no reason to keep this open. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-09-21 20:26 --- Also: Does hpux use the hppa atomics config, or the generic layer? If it uses the hppa atomics config, why isn't this a problem on hpux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug c++/29087] [4.1 Regression] More than 35000 switch cases crash cc1plus
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-21 20:27 --- Subject: Bug 29087 Author: steven Date: Thu Sep 21 20:27:36 2006 New Revision: 117120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117120 Log: 2006-09-21 Steven Bosscher [EMAIL PROTECTED] PR c++/29087 Backport from mainline: * parser.c (cp_parser_labeled_statement): Return nothing. Do not take in_statement_expr and in_compound as arguments. Rename to cp_parser_label_for_labeled_statement. Parse only the label, not the statement. (cp_parser_statement): Parse the statement of a labeled-statement from here, using tail recursion. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087
[Bug other/29173] gcc bugzilla help does not describe WAITING
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 20:36 --- Actually it is there, just in a different place: http://gcc.gnu.org/bugs/management.html -- 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=29173
[Bug middle-end/29171] forgotten memcpy with -ffreestanding -fwhole-program --combine
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-21 20:36 --- Confirmed, note waiting means waiting for the reporter to get back to us about a question, it should have been obvious anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-21 20:36:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
[Bug middle-end/29174] does not recognize memcpy and optimize it
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 20:37 --- Yes this is known issue. http://www.gccsummit.org/2006/view_abstract.php?content_key=27 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-21 20:37:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29174
[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage
--- Comment #8 from dwmw2 at infradead dot org 2006-09-21 20:38 --- Apologies -- GCC bugzilla mail was going missing due to being sent with a bogus sender address. Will dig out a current test case if it's still an issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
[Bug middle-end/29174] does not recognize memcpy and optimize it
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 20:39 --- Also mentioned in with results also: http://www.gccsummit.org/2006/2006-GCC-Summit-Proceedings.pdf -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29174
[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported
--- Comment #2 from pvanvugt at axys dot com 2006-09-21 20:49 --- (In reply to comment #1) This is not a bug as char pointers are special by the C standard. char is a different type from either unsigned char or signed char. Also you should not use -funsigned-char/-fsigned-char unless you know what you are doing because it could change the ABI. I have encountered this issue as well. I am using the gcc 4.1.1 cross-compiler for an embedded arm-elf target, running under cygwin. I am using a string function library (included with eCos) that uses char rather than signed char or unsigned char as its string pointer data type. I do not consider this use of char to be very portable, as its signedness may depend on the architecture, so I have chosen to explicitly use type unsigned char for all my string pointers and to use the -funsigned-char compiler option to force all the chars in my string function library to be unsigned as well. In principle, this seems like a very reasonable choice. I would expect that this switch should cause char and unsigned char to have the same sign, but, if I compile the following code with the -funsigned-char flag: char char_var = 0xFF; char *pchar_var = char_var; unsigned char *puchar_var = pchar_var; I get warning: pointer targets in initialization differ in signedness, and other such warnings for the rest of my code about the targets of pointers to chars and unsigned chars having different signs. This is an illogical result, unless char is neither signed or unsigned. Finally, I can see how this might break the ABI when linking with precompiled libraries for the target architecture that have used a different signedness for their chars, but I don't see how this would be a problem for me. Peter van Vugt (nospam_pvanvugt at axys dot com) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28912
[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-21 21:03 --- (In reply to comment #2) (In reply to comment #1) This is not a bug as char pointers are special by the C standard. char is a different type from either unsigned char or signed char. Also you should not use -funsigned-char/-fsigned-char unless you know what you are doing because it could change the ABI. I have encountered this issue as well. I am using the gcc 4.1.1 cross-compiler for an embedded arm-elf target, running under cygwin. I am using a string function library (included with eCos) that uses char rather than signed char or unsigned char as its string pointer data type. I do not consider this use of char to be very portable, as its signedness may depend on the architecture, so I have chosen to explicitly use type unsigned char for all my string pointers and to use the -funsigned-char compiler option to force all the chars in my string function library to be unsigned as well. In principle, this seems like a very reasonable choice. I would expect that this switch should cause char and unsigned char to have the same sign, but, if I compile the following code with the -funsigned-char flag: char char_var = 0xFF; char *pchar_var = char_var; unsigned char *puchar_var = pchar_var; In C, char is special compared to int, etc. It can default to either signed or unsigned and is a different type from the explicate signed/unsigned char. 6.2.5/15 and note 35 explains that char, signed char and unsigned char are always different types unlike int and signed int. This does not matter on the options you use either, they are always different types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28912
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-09-21 21:10 ---
Whoops, Janis, you are right. Sorry for the false alarm. The fancy dejagnu line
I spit out at you does nothing.
I also tried to hack up this as you suggested:
Index: testsuite/lib/libstdc++.exp
===
--- testsuite/lib/libstdc++.exp (revision 117118)
+++ testsuite/lib/libstdc++.exp (working copy)
@@ -350,8 +350,14 @@
}
lappend options compiler=$cxx_final
-lappend options timeout=600
+# This is a hack to set the timeout higher.
+if [target_info exists gcc,timeout] {
+lappend options timeout=[target_info gcc,timeout]
+} else {
+lappend options timeout=600
+}
+
return [target_compile $source $dest $type $options]
}
However, I'm not quite sure how to test that people can over-ride timeout now.
Can any testsuite maintainer help please? Just some clear directions on how to
do this stuff would be appreciated.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported
--- Comment #4 from gcc at brainhub dot org 2006-09-21 21:19 --- I accepts Andrew's point, but note that you will get errors, not warnings, for identical C++ code. The problem is exacerbate by libc prototypes such as size_t strlen(const char *s). If you want to use libc functions, perhaps for their efficient __built_in equivalents, all your strings will need to be char * strings or you need to use explicit casts. Most of code today is assuming unsigned char * strings; UTF-8 strings are unsigned char * strings, for example. Given this inconsistency it would be nice to have new option in gcc to suppress char-related signedness warnings. In many projects these warnings are just a noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28912
[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-21 21:24 --- (In reply to comment #4) I accepts Andrew's point, but note that you will get errors, not warnings, for identical C++ code. Right, this is still invalid code in both C and C++, just in the C front-end we decided to warn by default instead of error out. You can get an error with the C front-end by doing -pednatic-errors The problem is exacerbate by libc prototypes such as size_t strlen(const char *s). Because that is what the C (and C++) standard defines the prototypes as. As I mentioned your code is invalid according to the C (and C++) standard so warning is the correct thing to do. I would think you should not care about the signedness of char really. The agrument about UTF-8 is really bogus as you can do: unsigned char a = *b; where b is a pointer to char and get the correct result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28912
[Bug c++/29087] [4.1 Regression] More than 35000 switch cases crash cc1plus
--- Comment #11 from steven at gcc dot gnu dot org 2006-09-21 21:31 --- Fixed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087
[Bug c++/29087] [4.1 Regression] More than 35000 switch cases crash cc1plus
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-21 21:32 --- Denis, this should be fixed in the next release of GCC 4.1 (which will be GCC 4.1.2) and in GCC 4.2. Thanks for reporting the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087
[Bug c++/29175] New: ICE on invalid: C++ static variable length array
Compiling this invalid C++ code with current mainline:
void foo() { static int c = 2; static const char *a[][c] = { { 1, 2 } }; }
gives me:
foo.cc: In function void foo():
foo.cc:1: internal compiler error: in tree_low_cst, at tree.c:4519
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
It should instead say something along the lines of
foo.cc:1: error: array bound is not an integer constant
--
Summary: ICE on invalid: C++ static variable length array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29175
[Bug c++/29016] [4.2 Regression] tree check: expected class 'expression', have 'exceptional' (baselink) in get_base_var, at ipa-utils.c:224
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-09-21 22:19 --- Subject: Bug 29016 Author: mmitchel Date: Thu Sep 21 22:18:54 2006 New Revision: 117123 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117123 Log: PR c++/29016 * typeck.c (build_unary_op): Don't form an ADDR_EXPR around a BASELINK. PR c++/29016 * g++.dg/init/ptrfn1.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/ptrfn1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
