[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails
--- Additional Comments From bje at gcc dot gnu dot org 2004-10-15 06:07 ---
gen_subprogram_die is indeed being called for the decl of `t'.
The problem seems a bit more subtle. This program illustrates the problem:
/*
Fails with:
gcc foo.c -DSTATIC=static -O3 -dA -S -gdwarf-2
Succeeds with:
gcc foo.c -O3 -dA -S -gdwarf-2
*/
#ifndef STATIC
#define STATIC
#endif
STATIC int f () { return 3; }
int main() { return f (); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17924
[Bug c++/18007] New: Template template specialization matching problem
[forwarded from http://bugs.debian.org/269513]
Gcc 3.3 and gcc 3.4 both give the error message error: `type' is not
a member of `outerdummy::innerdummyint ' when trying to compile
the following:
templatetypename dummy_var
struct dummy { };
templatetemplatetypename class outer_func
struct outer {
templatetypename inner_var
struct inner { };
templatetypename dummy_var
struct innerouter_funcdummy_var { typedef dummy_var type; };
};
int main(){
outerdummy::innerdummyint ::type var = 0;
return var;
}
Both cxx (Digital's compiler) and icc (Intel's compiler) have no such
problem. It appears that gcc does not properly match against the
specialized inner struct in this case (i.e. it fails to match when the
specialized parameter is based on a template template parameter of an
enclosing struct).
-T
PS: Note that the following version (which contains an even more
explicit specialization) also does not work with gcc (and also does
work with both cxx and icc):
templatetemplatetypename class outer_func
struct outer {
templatetypename inner_var, typename dummy=void
struct inner { };
templatetypename dummy
struct innerouter_funcint,dummy { typedef int type; };
};
--
Summary: Template template specialization matching problem
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18007
[Bug c++/18007] Template template specialization matching problem
-- What|Removed |Added Known to fail||3.3.5 3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18007
[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails
--- Additional Comments From bje at gcc dot gnu dot org 2004-10-15 06:43 --- Actually, Pinski is right ;-/ gen_subprogram_die() is not being called. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17924
[Bug rtl-optimization/17972] [3.3 Regression] const/pure functions result in bad asm
--- Additional Comments From amodra at bigpond dot net dot au 2004-10-15 06:47 --- Crucial detail that Andrew may have overlooked: Only happens when compiling the testcase as c++. -- What|Removed |Added Target Milestone|3.3.6 |--- Version|3.3.4 |3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug middle-end/17746] [4.0 Regression] ICE when building the shared Ada RTS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-15 06:58 --- FYI, diff -u my_x86_64_run your_sparc_run gives: +FAIL: c391002 +FAIL: c940006 +FAIL: c951001 +FAIL: c954023 -FAIL: c54a13b -FAIL: c61008a -FAIL: c64104c -FAIL: cc51003 -FAIL: cc70a01 Thanks! This is very helpful. I was afraid SPARC was very broken wrt Ada but it appears that it is even in slightly better shape than x86_64. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug middle-end/17793] [4.0 Regression] Ada bootstrap failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-15 07:30 --- Investigating. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17793
[Bug c++/15369] Wrong line number for static constructor function
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-15 07:39 --- The bug here happens because once we start processing functions, input_location changes effectively at random. E.g. walk_tree sets input_location based on the tree node that we're currently processing. Which is, frankly, insane. It also turns out to be remarkably difficult to get hold of the locus for the end of file because c-lex and the c++ front end conspire to discard the locus that the preprocessor helpfully collects for CPP_EOF. I'll note that this has only worked by chance in previous versions and on mainline. What line number we get for the static constructors depends on what order we find ourselves processing the functions (inlined, not inlined, etc). I.e. essentially random. So it seems a streach to call this a 3.4 regression. There appears to be no non-invasive solution for this for 3.4. My personal feeling is that some C++ lexer guy ought to fix this for mainline, and we should WONTFIX the problem for previous versions. It's definitely non-critical and there's a perfectly good workaround for users -- set breakpoints on function names rather than line numbers. -- What|Removed |Added Severity|normal |minor Component|debug |c++ GCC build triplet|i686-pc-linux | GCC host triplet|i686-pc-linux | GCC target triplet|i686-pc-linux | Known to work|4.0 3.3.3 | Last reconfirmed|2004-05-10 20:28:06 |2004-10-15 07:39:18 date|| Summary|[3.4 Regression] Compiler |Wrong line number for |emits wrong linenumbers |static constructor function Target Milestone|3.4.3 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15369
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-15 08:00 --- Aaron, please check it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug target/17962] [4.0 Regression] small fp vector uses sse/mmx vectors and is not aligned
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17962
[Bug target/17962] [4.0 Regression] small fp vector uses sse/mmx vectors and is not aligned
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-15 08:37 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01266.html -- What|Removed |Added Status|ASSIGNED|WAITING Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17962
[Bug c/18008] New: Duplicate mask on bitfield insertion
This code
struct B { unsigned b : 2; };
void store (struct B *b, int v)
{ b-b = v;}
produces this assembler
store:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %ecx
movb 12(%ebp), %dl
andl $3, %edx
andl $3, %edx
movl (%ecx), %eax
andl $-4, %eax
orl %edx, %eax
movl %eax, (%ecx)
leave
ret
Those two andl $3's get inserted becuase rtl expansion generates somethine
daft. Here's the bits of rtl
(insn 13 11 14 1 (parallel [
(set (reg:QI 60)
(and:QI (subreg:QI (reg/v:SI 59 [ v ]) 0)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 15 14 16 1 (parallel [
(set (reg:SI 62)
(zero_extend:SI (reg:QI 60)))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 16 15 17 1 (parallel [
(set (reg:SI 63)
(and:SI (reg:SI 62)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
huh?
--
Summary: Duplicate mask on bitfield insertion
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathan at gcc dot gnu dot org
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=18008
[Bug target/18009] New: ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)
This testcase:
void Parse_UV_Vect (double UV_Vect[2])
{
double Express[4];
int Terms;
for(Terms=0;Terms2;Terms++)
UV_Vect[Terms]=Express[Terms];
}
with 'gcc -O2 -march=pentium4 -ftree-vectorize -S err.cpp' ICEs:
err.cpp: In function `void Parse_UV_Vect(double*)':
err.cpp:1: internal compiler error: in vect_transform_stmt, at
tree-vectorizer.c:2625
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in vect_transform_stmt, at tree-vectorizer.c:2625
(testcase included)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: pentium4-pc-linux-gnu
GCC host triplet: pentium4-pc-linux-gnu
GCC target triplet: pentium4-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18009
[Bug driver/18006] Please replace vfork() with fork()
--- Additional Comments From schwab at suse dot de 2004-10-15 09:32 --- - vfork() is deprecated -- it was a BSD kludge from old no-MMU-days (a politically-correct reason :-). Use of vfork is still a win if you are going to call execve anyway because the address space does not need to be copied. - At least in Linux, vfork()s can't be followed by strace/ltrace, which makes debugging obscure situations MUCH harder. This is wrong. At least strace has no problem following vfork. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
[Bug driver/18006] Please replace vfork() with fork()
--- Additional Comments From d dot yu dot bolkhovityanov at inp dot nsk dot su 2004-10-15 09:46 --- Use of vfork is still a win if you are going to call execve anyway because the address space does not need to be copied. Yes, it is a tiny win, since vfork() doesn't require copying of page tables, as opposed to fork(). But address space isn't copied anyway, thanks to copy-on-write strategy. - At least in Linux, vfork()s can't be followed by strace/ltrace, which makes debugging obscure situations MUCH harder. This is wrong. At least strace has no problem following vfork. From strace(1) (Fedora Core 2): Currently (Linux 2.3.25), strace(1) cannot follow vfork() and requires a kernel patch. That is true at least under 2.4; 2.6 shows somewhat better behaviour. But there is a HUGE amount of 2.4 installations, which will remain for long time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
[Bug driver/18006] Please replace vfork() with fork()
--- Additional Comments From schwab at suse dot de 2004-10-15 09:46 --- This is wrong. At least strace has no problem following vfork. I take that back. My tests were broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
[Bug debug/17076] [3.4 regression] ICE on variable size array initialization in debug mode in C++
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-15 10:06 --- Alas this is not fixed with the patch for PR 14900. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|RESOLVED|UNCONFIRMED Component|c++ |debug Keywords||ice-on-valid-code, monitored Known to fail||3.4.0 3.4.3 Known to work||3.3.5 4.0.0 Resolution|DUPLICATE | Summary|ICE on variable size array |[3.4 regression] ICE on |initialization in debug mode|variable size array |in C++ |initialization in debug mode ||in C++ Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17076
[Bug target/15286] ICE cause by reload
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-10-15 10:46 --- As I understand it, generation of subregs the hardware does not support should be prevented by the CANNOT_CHANGE_MODE_CLASS mechanism. Reload would reload the full inner reg into a register that allows the desired mode change instead. Could you try to find out why this doesn't work? Does reload fail to call CANNOT_CHANGE_MODE_CLASS somewhere? Or is the rs6000 definition of that macro incorrect? -- What|Removed |Added Known to fail|3.3.3 3.4.0 4.0 |3.3.3 3.4.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
[Bug target/18010] New: bad unwind info due to multiple returns (missing epilogue)
It appears there is a long-standing and quite nasty bug in GCC. I believe all versions of GCC which allow for reordering of basic-blocks are affected. In the example I attached, func has two epilogues, but the unwind info looks like this: func: [0x0-0x1d0], info at +0x0 v1, flags=0x0 (), len=32 bytes R2:prologue_gr(mask=[rp,ar.pfs],grsave=r37,rlen=11) P7:pfs_when(t=0) P7:mem_stack_f(t=1,size=4096) P7:pr_when(t=2) P3:pr_gr(reg=r40) P7:lc_when(t=7) P3:lc_gr(reg=r41) P7:rp_when(t=10) R3:body(rlen=46) B1:label_state(label=1) B2:epilogue(t=1,ecount=0) R1:body(rlen=30) B1:copy_state(label=1) Note that there is only one epilogue directive. The stack-popping instruction in the second body region is not marked at all, meaning that the unwind info will be incorrect once the stack got popped in the second body region. It's easiest to reproduce this bug with a libunwind-enabled gdb: $ gcc -v 21 | grep 'version' gcc version 3.4.1 $ gcc -O2 -Wall .test-ptrace-misc.c ident.c -o test-ptrace-misc $ gdb ./test-ptrace-misc (gdb) b 0x4aa2 # this should be the last instruction in func (gdb) r Starting program: /home/davidm/src/unwind/build-opt/tests/test-ptrace-misc Program received signal SIGUSR1, User defined signal 1. 0x200ef042 in kill () from /lib/tls/libc.so.6.1 (gdb) c Continuing. Breakpoint 1, 0x4aa2 in func () (gdb) bt #0 0x4aa2 in func () #1 0x4970 in func () #2 0x40002070 in bar () #3 0x in ?? () #4 0x in ?? () ...etc... (You can verify that gdb is picking up libunwind by starting it with environment variable LD_DEBUG set to files; you should see a line along the lines of: 16559: file=libunwind-ia64.so; generating link map while gdb is starting up.) To fix this bug, GCC should be emitting a .restore sp directive in front of every instruction which pops the stack-pointer. -- Summary: bad unwind info due to multiple returns (missing epilogue) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davidm at hpl dot hp dot com CC: davidm at hpl dot hp dot com,gcc-bugs at gcc dot gnu dot org,wilson at gcc dot gnu dot org GCC build triplet: ia64-hp-linux GCC host triplet: ia64-hp-linux GCC target triplet: ia64-hp-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18010
[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)
--- Additional Comments From davidm at hpl dot hp dot com 2004-10-15 11:15 --- Created an attachment (id=7356) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7356action=view) test-ptrace-misc.c Test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18010
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug driver/18006] Please replace vfork() with fork()
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 11:55 --- But who cares that is strace bug which should be fixed because it works on the BSD (and in fact the BSD got rid of vfork for a while but now they are adding it back because they found it can faster). So closing as will not fix. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
[Bug c++/10479] __alignof__(double) not compile time constant inside template class
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |giovannibajo at gcc dot gnu |dot org |dot org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10479
gcc says undefined symbols, nm finds those symbols in the .so
Dear all, here follows some strange behaviour using gcc, if someone has any idea to fix :-) We have some strange link errors while linking some servers. Our code is linked with Tibco Hawk 4.2 The following lines shows only errors on class AmiStatus but there are others problems (btw all link errors are related to symbols present in libtibhawkamicpp.so) Compilers tested were gcc 3.2.2 and 3.4.2 Our source tree is also compilable on SunOS and AIX, using Hawk 4.2 libraries for those platforms. Linking didn't produce any error ... Is it a gcc bug ? are the Hawk libraries for linux broken ? Whole gcc output on demand (12Mb) meaningful details : gcc link stage error messages [grep on AmiStatus] /mylibpath/libHAT03.so: undefined reference to `AmiStatus::AmiStatus(void*)' /mylibpath/libKMI03.so: undefined reference to `AmiStatus::getText()' /mylibpath/libKMI03.so: undefined reference to `AmiStatus::operator=(AmiStatus const)' /mylibpath/libHAT03.so: undefined reference to `AmiStatus::setStatus(int, char const*, ...)' /mylibpath/libKMI03.so: undefined reference to `AmiStatus::AmiStatus()' /mylibpath/libKMI03.so: undefined reference to `AmiStatus::operator!=(void*)' /mylibpath/libHAT03.so: undefined reference to `AmiStatus::operator==(void*)' additional gcc output obtained in link stage using -Wl,--trace,--print-map,--cref [grep on AmiStatus] AmiStatus type_info function /mylibpath/libtibhawkamicpp.so [is a B entry for nm] AmiStatus virtual table /mylibpath/libtibhawkamicpp.so [is a V entry for nm] AmiStatus::~AmiStatus(void) /mylibpath/libtibhawkamicpp.so [is a W entry for nm] AmiStatus::AmiStatus()/mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::AmiStatus(void*) /mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::getText() /mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::operator!=(void*) /mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::operator=(AmiStatus const)/mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::operator==(void*) /mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::setStatus(int, char const*, ...) /mylibpath/libHAT03.so [is a T entry for nm] AmiStatus::~AmiStatus() /mylibpath/libKMI03.so [is a T entry for nm] AmiStatus::~AmiStatus() /mylibpath/libKMI03.so [is a T entry for nm] typeinfo for AmiStatus/mylibpath/libKMI03.so typeinfo name for AmiStatus /mylibpath/libKMI03.so vtable for AmiStatus /mylibpath/libKMI03.so nm -A on /mylibpath/libtibhawkamicpp.so, as you can see undefined references are not so undefined at all (T) /mylibpath/libtibhawkamicpp.so:4230 T AmiStatus::AmiStatus(void) /mylibpath/libtibhawkamicpp.so:69c0 W AmiStatus::~AmiStatus(void) /mylibpath/libtibhawkamicpp.so:4260 T AmiStatus::AmiStatus(ami_ErrorCode) /mylibpath/libtibhawkamicpp.so:43c0 T AmiStatus::AmiStatus(int) /mylibpath/libtibhawkamicpp.so:4400 T AmiStatus::AmiStatus(int, char const *) /mylibpath/libtibhawkamicpp.so:4340 T AmiStatus::AmiStatus(void *) /mylibpath/libtibhawkamicpp.so:42a0 T AmiStatus::AmiStatus(AmiStatus const ) /mylibpath/libtibhawkamicpp.so:44d0 T AmiStatus::operator=(ami_ErrorCode) /mylibpath/libtibhawkamicpp.so:4510 T AmiStatus::operator=(void *) /mylibpath/libtibhawkamicpp.so:45a0 T AmiStatus::operator=(AmiStatus const ) /mylibpath/libtibhawkamicpp.so:4440 T AmiStatus::duplicateError(void) /mylibpath/libtibhawkamicpp.so:47a0 T AmiStatus::operator==(ami_ErrorCode) /mylibpath/libtibhawkamicpp.so:4700 T AmiStatus::operator==(void *) /mylibpath/libtibhawkamicpp.so:4640 T AmiStatus::operator==(AmiStatus const ) /mylibpath/libtibhawkamicpp.so:4890 T AmiStatus::getCode(void) /mylibpath/libtibhawkamicpp.so:4960 T AmiStatus::getFile(void) /mylibpath/libtibhawkamicpp.so:4990 T AmiStatus::getLine(void) /mylibpath/libtibhawkamicpp.so:48c0 T AmiStatus::getText(void) /mylibpath/libtibhawkamicpp.so:48f0 T AmiStatus::getThread(void) /mylibpath/libtibhawkamicpp.so:47e0 T AmiStatus::operator!=(ami_ErrorCode) /mylibpath/libtibhawkamicpp.so:4750 T AmiStatus::operator!=(void *) /mylibpath/libtibhawkamicpp.so:46a0 T AmiStatus::operator!=(AmiStatus const ) /mylibpath/libtibhawkamicpp.so:4840 T AmiStatus::operator!(void) const /mylibpath/libtibhawkamicpp.so:4820 T AmiStatus::ok(void) const /mylibpath/libtibhawkamicpp.so:5bd0 T AmiAsyncMethod::sendError(AmiSubscription *, AmiStatus ) /mylibpath/libtibhawkamicpp.so:4920 T AmiStatus::setStatus(int, char const *,...) /mylibpath/libtibhawkamicpp.so:49c0 T AmiStatus::setStatusV(int, char const *, void *) /mylibpath/libtibhawkamicpp.so:4860 T AmiStatus::stamp(char const *,
[Bug tree-optimization/18009] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:38 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-10-15 12:38:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18009
[Bug c/18011] New: inlined returned type convertion
gcc -O2 -finline-functions -c gcc_bug.c
gcc_bug.c: In function `main':
gcc_bug.c:8: internal compiler error: in convert_move, at expr.c:597
Please submit a full bug report,
with preprocessed source if appropriate.
cat gcc_bug
float Flt (float a) { return a; }
int main(void) {
typedef void *(*func_t) (float);
union { void *ptr; float flt; } ret;
ret.ptr = ((func_t) Flt) (3.14);
return 0;
}
--
Summary: inlined returned type convertion
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent dot deniau at cern dot ch
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18011
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:45 --- Confirmed, this is a middle-end issue as the trees look good b-b = (unnamed type) (unsigned char) v; -- What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-10-15 12:45:55 date|| Summary|Duplicate mask on bitfield |[4.0 Regression] Duplicate |insertion |mask on bitfield insertion Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug c/18012] New: (invalid) convertion of inlined returned floatings
gcc -O2 -finline-functions -c gcc_bug.c
gcc_bug.c: In function `main':
gcc_bug.c:8: internal compiler error: in convert_move, at expr.c:597
Please submit a full bug report,
with preprocessed source if appropriate.
cat gcc_bug.c
float Flt (float a) { return a; }
int main(void) {
typedef void *(*func_t) (float);
union { void *ptr; float flt; } ret;
ret.ptr = ((func_t) Flt) (3.14);
return 0;
}
gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.4 (Debian 1:3.3.4-13)
--
Summary: (invalid) convertion of inlined returned floatings
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent dot deniau at cern dot ch
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18012
[Bug c/18012] (invalid) convertion of inlined returned floatings
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:49 --- *** This bug has been marked as a duplicate of 18011 *** *** This bug has been marked as a duplicate of 18011 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18012
[Bug c/18011] inlined returned type convertion
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:49 --- *** Bug 18012 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18011
[Bug c/18011] inlined returned type convertion
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:50 --- *** This bug has been marked as a duplicate of 12085 *** *** This bug has been marked as a duplicate of 12085 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18011
[Bug c/12085] [3.3/3.4 Regression] Internal compiler error in convert_move, at expr.c:504 with -O3 flag
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:51 --- *** Bug 18011 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||laurent dot deniau at cern ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12085
[Bug middle-end/18005] [4.0 Regression] ICE in fold-const.c/fold
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:55 --- The SSA_NAME lost its type (again). -- What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in fold-const.c/fold|[4.0 Regression] ICE in ||fold-const.c/fold Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18005
[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:55 --- I have a fix for the C front-end (the C++ front-end already works). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17529
[Bug c++/18007] Template template specialization matching problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 12:59 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2004-10-15 12:59:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18007
[Bug driver/18006] Please replace vfork() with fork()
--- Additional Comments From d dot yu dot bolkhovityanov at inp dot nsk dot su 2004-10-15 13:02 --- Andrew, this is not strace bug, but a vfork() bug that it can't be traced -- strace simply CAN'T do anything to fix it. If some versions of GCC use fork(), and others -- vfork(), so, GCC in fact supports both styles, right? So, can this be made at least configurable? And as for performance... Of course, vfork() is slightly faster, but the performance gain (microseconds?) is neglectable if compared with times spent on compilation and optimization... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
[Bug libfortran/17748] libgfortran contains undefined references to _environ
--- Additional Comments From peter at pogma dot com 2004-10-15 13:04 --- You want additional checks besides the crt_externs.h check in my patch? I think it highly unlikely that other platforms have this header, but if you like I can also check for the _NSGetEnviron function. It may take a little while though, I rm'ed the gcc tree I had checked out, was running out of disk space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17748
[Bug tree-optimization/18009] [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 13:13 --- This is a regression from two (or three) days ago. -- What|Removed |Added Summary|ICE in vect_transform_stmt, |[4.0 Regression] ICE in |at tree-vectorizer.c:2625 |vect_transform_stmt, at |(testcase included) |tree-vectorizer.c:2625 ||(testcase included) Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18009
[Bug middle-end/18005] [4.0 Regression] ICE in fold-const.c/fold
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 13:25
---
Confirmed, reduced to:
extern int printf (__const char *__restrict __format, ...);
const int nseq = 3;
const int nrnd = 50;
void fail () __attribute__ ((__noreturn__));
long random();
int
main (void)
{
long int rnd[3][nrnd];
char* state[nseq];
int s;
int i;
for (i = 0; i nrnd; ++i)
for (s = 0; s nseq; ++s)
if (rnd[s][i] != random ())
fail ();
return 0;
}
--
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org, spop at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-10-15 13:26:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18005
[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with -O2 -m4
--- Additional Comments From amylaar at gcc dot gnu dot org 2004-10-15 13:35
---
Your examples return an undefined value, which raises some extra issues, but
that is really a red herring; I see the same failure with:
int glob1;
int
adrreg01limm1_set (float *p0)
{
int r = 5;
p0[10] = (float) glob1;
return r;
}
compiled with -m4 -O2 -fPIC .
In particular, sched1 moves instruction past the return value copy and use.
after regmove:
(insn:HI 27 24 33 0 (set (reg/i:SI 0 r0 [ result ])
(const_int 5 [0x5])) 129 {movsi_ie} (nil)
(nil))
(insn:HI 33 27 0 0 (use (reg/i:SI 0 r0 [ result ])) -1 (insn_list:REG_DEP_TRUE
27 (nil))
(nil))
;; End of basic block 0, registers live:
0 [r0] 12 [r12] 14 [r14] 15 [r15] 145 [ap] 151 []
after sched1:
(insn:HI 27 14 47 1 (set (reg/i:SI 0 r0 [ result ])
(const_int 5 [0x5])) 129 {movsi_ie} (nil)
(nil))
(insn 47 27 40 1 (set (reg:SI 175)
(plus:SI (reg:SI 174)
(reg:SI 12 r12))) 23 {*addsi3_compact} (insn_list:REG_DEP_TRUE 46 (nil))
(expr_list:REG_DEAD (reg:SI 174)
(nil)))
(insn 40 47 48 1 (set (reg:SI 170)
(const:SI (unspec [
(symbol_ref:SI (__fpscr_values))
] 7))) 129 {movsi_ie} (nil)
(nil))
(insn 48 40 33 1 (set (reg:SI 173)
(mem/u:SI (reg:SI 175) [0 S4 A32])) 129 {movsi_ie}
(insn_list:REG_DEP_TRUE 47 (nil))
(expr_list:REG_DEAD (reg:SI 175)
(expr_list:REG_EQUAL (symbol_ref:SI (__fpscr_values))
(nil
(insn:HI 33 48 16 1 (use (reg/i:SI 0 r0 [ result ])) -1
(insn_list:REG_DEP_TRUE 27 (nil))
(nil))
(insn:HI 16 33 41 1 (set (reg/f:SI 162)
(mem/u:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 163)) [0 S4 A32])) 129 {movsi_ie}
(insn_list:REG_DEP_TRUE 14 (nil))
(expr_list:REG_DEAD (reg/f:SI 163)
(expr_list:REG_EQUAL (symbol_ref:SI (glob1) var_decl 0x401e415c glob1)
(nil
The return value use schould remain at the end of the basic block, and the
preceding return value copy should be in the same scheduling group.
--
What|Removed |Added
CC||amylaar at gcc dot gnu dot
||org
Last reconfirmed|2004-10-13 02:19:55 |2004-10-15 13:35:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16482
[Bug middle-end/16567] Nested function and variable-sized structure ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 13:49 --- Fixed: Search converges between 2004-07-16-trunk (#487) and 2004-07-17-trunk (#488). Committed the testcase so closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16567
[Bug middle-end/16567] Nested function and variable-sized structure ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 13:49 --- Subject: Bug 16567 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-15 13:49:21 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: nested-1.c Log message: 2004-10-14 Andrew Pinski [EMAIL PROTECTED] PR middle-end/16567 * gcc.c-torture/compile/nested-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/nested-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4454r2=1.4455 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16567
[Bug middle-end/16567] Nested function and variable-sized structure ICE
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16567
[Bug c/17913] [4.0 Regression] ICE jumping into statement expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 14:12 --- I was wrong in the sense it is not fold that is removing it but build_conditional_expr is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913
[Bug c/17913] [4.0 Regression] ICE jumping into statement expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 14:21 --- But if I remove the code in build_conditional_expr to fix the problem, we have the same problem in fold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913
[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with -O2 -m4
--- Additional Comments From kkojima at gcc dot gnu dot org 2004-10-15 14:23 --- I asked a question about this issue: http://gcc.gnu.org/ml/gcc/2004-10/msg00176.html and Toshi replied: http://gcc.gnu.org/ml/gcc/2004-10/msg00595.html Now I'm trying a patch in http://gcc.gnu.org/ml/gcc/2004-10/msg00600.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16482
[Bug c++/16301] [3.4/4.0 regression] ICE with strong using
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 14:30 --- Subject: Bug 16301 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-15 14:30:31 Modified files: gcc/cp : name-lookup.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: strong-using-4.C Log message: 2004-10-13 Andrew Pinski [EMAIL PROTECTED] PR c++/16301 * name-lookup.c (parse_using_directive): If we have a error_mark_node, do not set the decl namespace associations on it. 2004-10-14 Andrew Pinski [EMAIL PROTECTED] PR c++/16301 * g++.dg/lookup/strong-using-4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gccr1=1.86r2=1.87 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4434r2=1.4435 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/strong-using-4.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4455r2=1.4456 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16301
[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands
--- Additional Comments From amacleod at redhat dot com 2004-10-15 14:31 --- Is it the same bug? I have a compiler from oct 7th, and the original testcase fails as advertised, but the new one you have supplied appears to compile fine with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17529
[Bug c++/16301] [3.4 regression] ICE with strong using
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 14:32 --- I will apply the patch to 3.4 branch after some more testing. Fixed on the mainline. -- What|Removed |Added Known to fail|3.4.0 4.0.0 |3.4.0 Known to work|3.3.4 |3.3.4 4.0.0 Summary|[3.4/4.0 regression] ICE|[3.4 regression] ICE with |with strong using |strong using http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16301
[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 14:42 --- Yes it is the same bug (or at least a related one). The testcase I gave only fails yesterday between the time I patched remove_useless_statement and revert that patch because it caused other problems. The problem is that fold does not know how to fold *a (where a is array type) but fold_stmt does. And since we call fold_stmt with my patch to r_u_s reverted on the MODIFY_EXPR unlike the ASM_EXPR where we don't. Hopefully this explains what is going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17529
[Bug c++/18007] Template template specialization matching problem
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:50 --- This is a duplicate of PR 4882. W. *** This bug has been marked as a duplicate of 4882 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18007
[Bug c++/4882] fails to lookup a template specialization dependent of an outer template
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:50 --- *** Bug 18007 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
[Bug middle-end/17813] [4.0 regression] ada bootstrap failure on i486-linux
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-15 14:52 --- Confirmed on i586-redhat-linux-gnu as of today 10/15. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-15 14:52:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17813
[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 14:52 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01282.html. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17529
[Bug middle-end/17813] [4.0 regression] ada bootstrap failure on i486-linux
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-15 14:52 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17813
[Bug c++/4882] fails to lookup a template specialization dependent of an outer template
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:53 --- Likely related to PR 10574. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
[Bug middle-end/17746] [4.0 Regression] ICE when building the Ada RTS
-- What|Removed |Added Severity|normal |critical Summary|[4.0 Regression] ICE when |[4.0 Regression] ICE when |building the shared Ada RTS |building the Ada RTS http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug c++/13088] templatizing outer class hides specialization of inner template class
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:55 --- See also PR 4882. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13088
[Bug c++/4882] fails to lookup a template specialization dependent of an outer template
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:56 --- There quite some discussion on this matter in PR 13088. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From bangerth at dealii dot org 2004-10-15 15:03 --- I thought one of Kazu's PRs already had this case. Someone should go through his PRs... W. -- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug tree-optimization/16573] compiler crash while building groff with -fmudflap
--- Additional Comments From fche at redhat dot com 2004-10-15 15:21 --- I cannot reproduce this problem with current mainline any more. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16573
[Bug bootstrap/18013] New: make install failure: cannot touch `testsuite_wchar_t': Permission denied
A 'make install' fails with an error during installation of libstdc++. The configuration was: ../gcc/configure -prefix=/opt/gcc-3.4 --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking--enable-languages=c,c++,f77 --host=i686-pc-linux-gnu --enable-version-specific-runtime-libs The compiler was built with 'make bootstrap'. The error from 'make install' is: make[3]: Leaving directory `/home/scott/gnu/gcc-3.4/build-p4/i686-pc-linux-gnu/libstdc++-v3/po' make[2]: Leaving directory `/home/scott/gnu/gcc-3.4/build-p4/i686-pc-linux-gnu/libstdc++-v3/po' Making install in testsuite make[2]: Entering directory `/home/scott/gnu/gcc-3.4/build-p4/i686-pc-linux-gnu/libstdc++-v3/testsuite' touch testsuite_wchar_t touch: cannot touch `testsuite_wchar_t': Permission denied make[2]: *** [stamp_wchar] Error 1 make[2]: Leaving directory `/home/scott/gnu/gcc-3.4/build-p4/i686-pc-linux-gnu/libstdc++-v3/testsuite' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/scott/gnu/gcc-3.4/build-p4/i686-pc-linux-gnu/libstdc++-v3' make: *** [install-target-libstdc++-v3] Error 2 -- Summary: make install failure: cannot touch `testsuite_wchar_t': Permission denied Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coyote at coyotegulch dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18013
[Bug libfortran/17999] libfortran: uses some C99 functions (snprintf)
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-15 15:43 --- This is possible: libiberty/snprintf.c is GPL+exception -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-15 15:43:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17999
[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with -O2 -m4
--- Additional Comments From amylaar at gcc dot gnu dot org 2004-10-15 15:49
---
Looking closer, I see that sched-deps.c already has code to keep branches, calls
and USEs at the end of the last basic block.
The problem is that lcm.c:optimize_mode_switching has put some
instructions after the USE before sched1 is run.
In this code:
/* Split the edge from the entry block and the fallthrough edge to the
exit block, so that we can note that there NORMAL_MODE is supplied /
required. */
edge eg;
edge_iterator ei;
post_entry = split_edge (EDGE_SUCC (ENTRY_BLOCK_PTR, 0));
/* The only non-call predecessor at this stage is a block with a
fallthrough edge; there can be at most one, but there could be
none at all, e.g. when exit is called. */
pre_exit = 0;
FOR_EACH_EDGE (eg, ei, EXIT_BLOCK_PTR-preds)
if (eg-flags EDGE_FALLTHRU)
{
regset live_at_end = eg-src-global_live_at_end;
gcc_assert (!pre_exit);
pre_exit = split_edge (eg);
COPY_REG_SET (pre_exit-global_live_at_start, live_at_end);
COPY_REG_SET (pre_exit-global_live_at_end, live_at_end);
break;
}
}
We create a new block at the end to put the final mode switch into.
If the fall-through predecessor of the exit block is the only predecessor
of the exit block, and it ends with a USE, then instead of split_edge
we should use split_block, to place the USE and the preceding copy from
the result to the return value register into the new block.
I would write a patch for this, but the copyright assignment for STM is not
finished yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16482
[Bug bootstrap/18013] make install failure: cannot touch `testsuite_wchar_t': Permission denied
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 15:49 --- Is the object directory writable (or did you run out of space)? Because that is the only thing which cause this. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18013
[Bug c/11751] wrong evaluation order of an expression
-- What|Removed |Added Target Milestone|3.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug tree-optimization/18009] [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)
--- Additional Comments From bangerth at dealii dot org 2004-10-15 15:54 --- Indeed. It works with my snapshot from 20041013. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18009
[Bug libgcj/18014] New: java.util.Locale changes variant to upper case
import java.util.Locale;
public class LocaleTest {
public static void main(String[] s) {
java.util.ResourceBundle.getBundle(testbundle, new Locale(fi, FI,
regular));
}
}
tries to access the file testbundle_fi_FI_REGULAR.properties with gcj and
SUN's JDK 1.1.8. SUN's JDK 1.4.1_02 behaves differently and tries to to access
the file testbundle_fi_FI_regular.properties instead. Should gcj do the same?
--
Summary: java.util.Locale changes variant to upper case
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timo dot lindfors at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18014
[Bug libstdc++/18013] make install failure: cannot touch `testsuite_wchar_t': Permission denied
--- Additional Comments From coyote at coyotegulch dot com 2004-10-15 16:02 --- I can manually touch the file. The directory appears writable, and I have 40GB of free space. [EMAIL PROTECTED] ~/gnu/gcc-3.4/build-p4 $ ls /home/scott/gnu/gcc-3.4/build-p4/i686-pc-linux-gnu/libstdc++-v3 -l drwxr-xr-x 3 scott users 4096 Oct 15 10:55 testsuite [EMAIL PROTECTED] ~/gnu/gcc-3.4/build-p4 $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda3 76312224 32244088 40191652 45% / -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18013
[Bug libgcj/18014] java.util.Locale changes variant to upper case
--- Additional Comments From timo dot lindfors at iki dot fi 2004-10-15 16:04 --- Created an attachment (id=7357) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7357action=view) Remove variant.toUpperCase from java.lang.Locale -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18014
[Bug bootstrap/18015] New: No rule to make target 'gcc/libstdc++-v3/include/tr1/array', needed by `stamp-tr1'
Updated from CVS an hour or so ago... Configured with: ../gcc/configure -prefix=/opt/gcc-4.0 --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --enable-languages=c,c++,f95 --host=i686-pc-linux-gnu --enable-version-specific-runtime-libs Doing a 'make bootstrap' results in: make[3]: Entering directory `/home/scott/gnu/gcc-mainline/build-p4/i686-pc-linux-gnu/libstdc++-v3' Making all in include make[4]: Entering directory `/home/scott/gnu/gcc-mainline/build-p4/i686-pc-linux-gnu/libstdc++-v3/include' make[4]: *** No rule to make target `/home/scott/gnu/gcc-mainline/gcc/libstdc++-v3/include/tr1/array', needed by `stamp-tr1'. Stop. make[4]: Leaving directory `/home/scott/gnu/gcc-mainline/build-p4/i686-pc-linux-gnu/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/scott/gnu/gcc-mainline/build-p4/i686-pc-linux-gnu/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/scott/gnu/gcc-mainline/build-p4/i686-pc-linux-gnu/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/scott/gnu/gcc-mainline/build-p4' make: *** [bootstrap] Error 2 -- Summary: No rule to make target 'gcc/libstdc++- v3/include/tr1/array', needed by `stamp-tr1' Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coyote at coyotegulch dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18015
[Bug bootstrap/18015] No rule to make target 'gcc/libstdc++-v3/include/tr1/array', needed by `stamp-tr1'
--- Additional Comments From coyote at coyotegulch dot com 2004-10-15 16:27 --- This problem also occurs for x86_64-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18015
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-15 16:42 --- No, I don't think this is a duplicate of mine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug c++/18016] New: -Winit-self misses member variables initialized after : in ctor
First, my gcc version information:
% gcc -v
Reading specs from /usr/lib/gcc/i486-linux/3.4.2/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror i486-linux
Thread model: posix
gcc version 3.4.2 (Debian 3.4.2-2)
This is the gcc-3.4 package in debian, FYI, but this bug is not likely to be
debian-specific.
I'm excited to see the -Winit-self warning, but it fails to catch a common
problem, as illustrated by this code fragment (which I will include inline and
also as an attachment for convenience). This code has two cases of variables
initialized with themselves: one trivial int b = b case, and one more subtle A()
: a(a) case. g++ warns for one but not the other. Use this command:
g++-3.4 -c -Winit-self -Wuninitialized -O1 a.cc
on this file:
class A
{
public:
A() : a(a) // -- should generate a warning
{
}
int getA()
{
int b = b; // -- generates warning as it should
return this-a + b;
}
private:
int a;
};
int main()
{
A a;
return a.getA();
}
generates this output:
a.cc: In function `int main()':
a.cc:9: warning: 'b' might be used uninitialized in this function
It fails to warn for A::a being initialized with itself in the constructor.
One might also consider it to be a problem that A::getA's being inlined causes
the warning message to mention main() rather than getA() -- this problem is not
present if getA is not inlined. Anyway, the line number is okay, so this seems
pretty unimportant though still worthy of mention.
It would also be nice if -Winit-self would automatically add -Wuninitialized
instead of just not doing anything unless -Wuninitialized was also specified.
I'll mention that in a separate bug report.
--
Summary: -Winit-self misses member variables initialized after :
in ctor
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ejb at ql dot org
CC: ejb at ql dot org,gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux
GCC host triplet: i486-linux
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18016
[Bug c++/18016] -Winit-self misses member variables initialized after : in ctor
--- Additional Comments From ejb at ql dot org 2004-10-15 16:46 --- Created an attachment (id=7358) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7358action=view) source file that reproduces problem This attachment contains the code that is also inlined in the bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18016
[Bug tree-optimization/18009] [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-15 16:47 --- Dorit, the regression appeared with your patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00922.html Could you please have a look? -- What|Removed |Added CC||dorit at gcc dot gnu dot ||org, reichelt at gcc dot gnu ||dot org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18009
[Bug c/18017] New: -Winit-self should automatically turn on -Wuninitialized
The documentation clearly states that -Winit-self doesn't work without -Wuninitialized. I think it would be a lot better if it just automatically turned on -Wuninitialized instead. For example, compiling the example in bug 18016 with -Winit-self but not -Wuninitialized doesn't generate any warnings at all, which is as expected based on the documentation, but is still somewhat counter-intuitive. -- Summary: -Winit-self should automatically turn on -Wuninitialized Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: minor Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ejb at ql dot org CC: ejb at ql dot org,gcc-bugs at gcc dot gnu dot org GCC build triplet: any GCC host triplet: any GCC target triplet: any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18017
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-15 16:55 --- There are at least two strange things. 1. We emit two ands in the first place. 2. The combiner does not seem to be working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug c/18017] -Winit-self should automatically turn on -Wuninitialized
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:00 --- Not going to happen because people use int a = a; as to turn off uninitialize warnings (which is why -Winit-self was added in the first place). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18017
[Bug c++/18016] Warn about member variables initialized with itself
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:05 --- -Winit-self has nothing to do with this problem really. in this case :a(a) is equivalent to this-a = this-a; We should warn about this case even without -Winit-self or even -Wuninitialize as we can warn without optimization turned on. Note I added -Winit-self so I know what it was designed to do. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-10-15 17:05:57 date|| Summary|-Winit-self misses member |Warn about member variables |variables initialized after |initialized with itself |: in ctor | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18016
[Bug bootstrap/18015] No rule to make target 'gcc/libstdc++-v3/include/tr1/array', needed by `stamp-tr1'
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:09 --- Are you sure that you updated the CVS correctly as this works for me. You might have to use cvs up -d as new directories are not added unless you do. So closing as works for me since this looks like you forgot the -d or you have a tag somewhere. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18015
[Bug libstdc++/18013] make install failure: cannot touch `testsuite_wchar_t': Permission denied
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:10 --- This cannot be a GCC problem, something is wrong with your machine (I don't know what) because it works for a large number of other people and this part of the makefile has not changed for a long time. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18013
[Bug other/16820] Failure of all gcc.dg/compat/struct-layout-1 tests
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:13 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16820
[Bug tree-optimization/16573] compiler crash while building groff with -fmudflap
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16573
[Bug target/17984] Recent peephole2:s may cause internal compiler errors (2)
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17984
[Bug libstdc++/17937] Critical ~__pool troubles
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
[Bug c++/17891] An expression accepted as lvalue by compiler but not assigned at run time
-- What|Removed |Added Severity|critical|normal Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17891
[Bug fortran/17612] ICE in gfortran
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17612
[Bug tree-optimization/16632] A couple fold-const.c optimizations are non-functional
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16632
[Bug other/17762] treelang doesn't use mapped locations
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17762
[Bug rtl-optimization/16419] gcc.c-torture/execute/20040309-1.c fails on mips-elf
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16419
[Bug java/16658] errors compiling saxon xslt library
--- Additional Comments From jbarnett at 2wire dot com 2004-10-15 17:16 --- any luck trying to narrow down the fix for this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16658
[Bug c++/18018] New: ICE on dubious extern declaration
The extern declaration below probably doesn't make much sense. But when
putting this code into a C++ file (not C!)
void foo()
{
}
void bar()
{
extern void foo();
foo();
}
and compiling this with (the -g is important)
gcc -c -g test.cpp
I get this error:
/tmp/test.cpp: In function `void bar()':
/tmp/test.cpp:9: internal compiler error: in gen_subprogram_die, at
dwarf2out.c:11183
gcc is from today's CVS HEAD. g++ -v gives:
Reading specs from /opt/gcc-4.0/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: /home/porten/gcc/configure --enable-languages=c,c++
--prefix=/opt/gcc-4.0
Thread model: posix
gcc version 4.0.0 20041015 (experimental)
--
Summary: ICE on dubious extern declaration
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: porten at kde dot org
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=18018
[Bug c++/18018] ICE on dubious extern declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:41 --- *** This bug has been marked as a duplicate of 16792 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18018
[Bug debug/16792] [4.0 regression] ICE in gen_subprogram_die, at dwarf2out.c:11267
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 17:41 --- *** Bug 18018 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||porten at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16792
[Bug c/18019] New: -march=pentium4 generates word fetch instead of byte fetch
When compiling the testcase (strcpy()) with -Os -march=pentium4, GCC generates a
word-fetch
instead of a byte-fetch. This can provoke memory faults (e.g. at the end of a page).
Omitting -march=pentium4 generates correct code.
Here is the testcase:
char *
mystrcpy(char * __restrict to, const char * __restrict from)
{
char *save = to;
for (; (*to = *from); ++from, ++to);
return(save);
}
And the invocation: % gcc.fsf.pure.obj/gcc/xgcc -B gcc.fsf.pure.obj/gcc -Os -S
mystrcpy.c
-march=pentium4
And the result (error is marked):
.file mystrcpy.c
.text
.globl mystrcpy
.type mystrcpy, @function
mystrcpy:
pushl %ebp
movl%esp, %ebp
movl12(%ebp), %ecx
movl8(%ebp), %edx
jmp .L2
.L3:
incl%ecx
incl%edx
.L2:
movl(%ecx), %eax should be 'movb'
movb%al, (%edx)
testb %al, %al
jne .L3
movl8(%ebp), %eax
popl%ebp
ret
.size mystrcpy, .-mystrcpy
.ident GCC: (GNU) 4.0.0 20041015 (experimental)
.section.note.GNU-stack,,@progbits
--
Also reproducible on i686-apple-darwin.
--
Summary: -march=pentium4 generates word fetch instead of byte
fetch
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug c/18019] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From stuart at apple dot com 2004-10-15 18:05 --- Created an attachment (id=7359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7359action=view) testcase Attaching the testcase for covenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug c++/18020] New: issue with enum in a template
Here we go:
[EMAIL PROTECTED]:~ cat foo.cpp
template typename FOO
struct bar {
enum {
MASK = ((1 17)-1)
, IT_MASK = (~MASK)
, ITERATION_INC = (MASK+1)
};
};
int baz = barint::IT_MASK;
[EMAIL PROTECTED]:~ g++ -o /dev/null -c foo.cpp
foo.cpp: In instantiation of `barint':
foo.cpp:10: instantiated from here
foo.cpp:3: error: enumerator value for `IT_MASK' not integer constant
[EMAIL PROTECTED]:~ gcc -v
Reading specs from /openpkg/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ../configure --cache-file=./config.cache
--srcdir=/openpkg/RPM/TMP/gcc-3.4.2/obj/.. --prefix=/openpkg
--exec-prefix=/openpkg --includedir=/openpkg/include/gcc
--libexecdir=/openpkg/libexec/gcc --with-gxx-include-dir=/openpkg/include/g++
--with-local-prefix=/openpkg/lib/gcc --enable-languages=c,c++
--enable-threads=posix --disable-maintainer-mode --disable-shared --disable-nls
--with-gnu-ld --with-ld=/openpkg/bin/ld --with-gnu-as --with-as=/openpkg/bin/as
Thread model: posix
gcc version 3.4.2 (OpenPKG-CURRENT)
[EMAIL PROTECTED]:~ uname -a
Linux linux 2.4.21-99-smp4G #1 SMP Wed Sep 24 14:13:20 UTC 2003 i686 athlon i386
GNU/Linux
This is a Suse 9.0 with gcc from CURRENT OpenPKG. It works if you remove the
template declaration.
--
Summary: issue with enum in a template
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmorin1 at bloomberg dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18020
[Bug target/18019] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 18:12
---
This is definitely a target problem, the RTL is correct:
(insn:HI 23 22 24 (set (reg:QI 0 ax [orig:60 D.1459 ] [60])
(mem:QI (reg/v/f:SI 2 cx [orig:63 from ] [63]) [0 S1 A8])) 48 {*movqi_1} (nil)
(nil))
I think the comment in i386.md summarizies the issues:
;; Situation is quite tricky about when to choose full sized (SImode) move
;; over QImode moves. For Q_REG - Q_REG move we use full size only for
;; partial register dependency machines (such as AMD Athlon), where QImode
;; moves issue extra dependency and for partial register stalls machines
;; that don't use QImode patterns (and QImode move cause stall on the next
;; instruction).
;;
;; For loads of Q_REG to NONQ_REG we use full sized moves except for partial
;; register stall machines with, where we use QImode instructions, since
;; partial register stall can be caused there. Then we use movzx.
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug c++/18020] issue with enum in a template
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 18:21 --- Hmm, this works for me on 3.4.2, can you try not with a OpenPKG package? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18020
