[Bug middle-end/19551] [3.4/4.0 Regression] LAPACK routine claic1.f bug
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-21 08:14 --- The test cases from the original description and from commen #5 work correctly at -O0, -O1, -O2 and -O3 on ia64-unknown-linux-gnu with the 20050116 snapshot. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug c++/18698] [3.4/4.0 regression] Error message using using for code not using using ;-)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 08:14 --- (In reply to comment #2) The error message shows 'using-declaration' while it is actually an 'access-declaration' (section 11.3 in the standard). But it looks like GCC does not differentiate between them when reporting a bug. Also shouldn't we warn about access-declaration as they are deprecated? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18698
[Bug c++/18698] [3.4/4.0 regression] Error message using using for code not using using ;-)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 08:16 --- (In reply to comment #3) But it looks like GCC does not differentiate between them when reporting a bug. s/bug/error/ A way to have GCC to differeentiate them is to add an argument to do_class_using_decl. And pass that code in parser for Access declaration is for Access declaration and not for using-declaration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18698
[Bug tree-optimization/18219] [4.0 Regression] gcc-4.0.0 bloats code by 31%
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-01-21 08:18 --- Subject: Re: [4.0 Regression] gcc-4.0.0 bloats code by 31% --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 07:57 --- I think one of the problems is that ivopts causes out of ssa not to Coalesce two SSA_NAME: Before out of ssa: D.1127_16 = *ivtmp.8_9; D.1128_21 = *ivtmp.12_30; D.1129_22 = D.1127_16 - D.1128_21; *ivtmp.12_30 = D.1129_22; ivtmp.3_17 = ivtmp.3_18 + 1; # ivtmp.12_30 = PHI ivtmp.12_35(0), ivtmp.12_31(1); # ivtmp.8_9 = PHI ivtmp.8_29(0), ivtmp.8_7(1); # ivtmp.3_18 = PHI 0(0), ivtmp.3_17(1); L1:; ivtmp.8_7 = ivtmp.8_9 + 4B; ivtmp.12_31 = ivtmp.12_30 + 4B; D.1171_37 = ivtmp.3_18 + D.1163_6; i_38 = (int) D.1171_37; if (i_38 = maxLen_4) goto L0; else goto L2; After: L0:; *ivtmp.12 = *ivtmp.17 - *ivtmp.12; ivtmp.3 = ivtmp.3 + 1; ivtmp.17 = ivtmp.8; ivtmp.12 = ivtmp.16; L1:; ivtmp.8 = ivtmp.17 + 4B; ivtmp.16 = ivtmp.12 + 4B; if ((int) (ivtmp.3 + D.1163) = maxLen) goto L0; else goto L2; Note how there are two moves in the BB for L0. Coalesce list: (6)ivtmp.12_30 (7)ivtmp.12_31 [map: 6, 7] : Fail due to conflict Coalesce list: (1)ivtmp.8_7 (2)ivtmp.8_9 [map: 1, 2] : Fail due to conflict I am fairly sure that ivopts themselves create both ivtmp.12 and ivtmp.8 such that life ranges of their ssa names do not overlap. However some of the later passes (most probably dom) propagates ivtmp.8_9 to expressions after definition of ivtmp.8_7. It might help to add pass that would transform this code to the following, thus enabling the coalescing of ivs. I will give it a try. D.1127_16 = *ivtmp.8.9; D.1128_21 = *ivtmp.12.30; D.1129_22 = D.1127_16 - D.1128_21; *ivtmp.12.30 = D.1129_22; ivtmp.3_17 = ivtmp.3_18 + 1; # ivtmp.12_30 = PHI ivtmp.12_35(0), ivtmp.12_31(1); # ivtmp.8_9 = PHI ivtmp.8_29(0), ivtmp.8_7(1); # ivtmp.3_18 = PHI 0(0), ivtmp.3_17(1); L1:; ivtmp.8.9 = ivtmp.8_9; ivtmp.8_7 = ivtmp.8_9 + 4B; ivtmp.12.30 = ivtmp.12_30; ivtmp.12_31 = ivtmp.12_30 + 4B; D.1171_37 = ivtmp.3_18 + D.1163_6; i_38 = (int) D.1171_37; if (i_38 = maxLen_4) goto L0; else goto L2; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug libstdc++/19545] static libstdc++.a does not link against shared objects
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21 08:55 --- --with-pic when building the db lib (that is what i currently try to compile on all platforms), or when building gcc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
[Bug libstdc++/19545] static libstdc++.a does not link against shared objects
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21 09:00 --- i get exactly the same error if i use --with-pic when configuring db-4.3.27. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
[Bug libstdc++/19545] static libstdc++.a does not link against shared objects
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21 09:05 --- comping gcc again using --with-pic. just saw the option in gcc-3.4.3/libstdc++- v3/configure ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 09:10 --- Your test case in comment #2 has syntax errors. Please provide something that does compile. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 09:13 --- The test case in comment #1 I mean, of course. You also did not specify how you compiled the test. This bug report misses basically *all* the information we need to do anything useful for you. Please read http://gcc.gnu.org/bugs.html and give us the things we need ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug libstdc++/19545] static libstdc++.a does not link against shared objects
--- Additional Comments From niki dot waibel at gmx dot net 2005-01-21 09:20 --- YES! everything fine now. compiling gcc using --with-pic solved the problem. thanks a lot for that hint! niki -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19545
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-21
09:43 ---
procedure was simple. The distro I am using on my amd64 is PLD
(www.pld-linux.org).
I got their openssl.spec, changed .rpmmacros to use gcc-4.0 for compilaition.
gcc was prepared from sources, I do recompile it quite often.
what params spec is giving to ./config in openssl ?
./Configure --openssldir=%{_var}/lib/%{name} linux-x86_64 shared debug
I've added debug, and --save-temps to OPTFLAGS, so I can get dumps.
where --openssldir doesn't matter in that case.
From that compiler uses:
gcc-4.0 -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-DOPENSSL_NO_KRB5 -m64 -DL_ENDIAN -DTERMIO -O2 -g --save-temps -Wall
-DMD32_REG_T=int -c plus some -I options.
I'll attach both full *.i and *.s file for (probably) the one that crashes.
I can provide you with access to that box if needed, or put somewhere tar.bz2
of build tree of made sources. Whatever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
-- What|Removed |Added Target Milestone|3.4.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
[Bug c++/17115] [3.3 Regression] -Winline does not respect __attribute__((__noinline__))
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21 10:02 --- Subject: Bug 17115 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-01-21 10:02:31 Modified files: gcc: ChangeLog tree-inline.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: Winline-4.C Log message: PR c++/17115 * tree-inline.c (expand_call_inline): Do not warn for functions marked with attribute noinline. PR c++/17115 * g++.dg/warn/Winline-4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1053r2=1.16114.2.1054 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.38.2.12r2=1.38.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.396r2=1.2261.2.397 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Winline-4.C.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.42.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17115
[Bug c++/17115] [3.3 Regression] -Winline does not respect __attribute__((__noinline__))
--- Additional Comments From giovannibajo at libero dot it 2005-01-21 10:03 --- This is now fixed in GCC 3.3.6, GCC 3.4.3 and GCC 4.0.0. Thanks for your report Markus! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17115
[Bug target/19548] [3.4/4.0 regression] RTEMS CPP specs not merged from 3.2/3.2 branches
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-21
10:04 ---
(In reply to comment #2)
commit was not there so I would assume this could clarify as obvious.
OK, thanks.
However, one thought:
In gcc 3.4 CPP_OS_RTEMS_SPEC had been part of svr4.h.
What do you think about moving CPP_OS_RTEMS_SPEC into rs6000/rtems.h, i.e. about
a applying this patch to gcc-4.0:
Index: gcc/config/rs6000/rtems.h
===
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rtems.h,v
retrieving revision 1.20
diff -u -r1.20 rtems.h
--- gcc/config/rs6000/rtems.h 17 Oct 2004 18:09:44 - 1.20
+++ gcc/config/rs6000/rtems.h 21 Jan 2005 10:02:12 -
@@ -38,3 +38,20 @@
#undef CPP_OS_DEFAULT_SPEC
#define CPP_OS_DEFAULT_SPEC %(cpp_os_rtems)
+
+#define CPP_OS_RTEMS_SPEC \
+%{!mcpu*: %{!Dppc*: %{!Dmpc*: -Dmpc750} } }\
+%{mcpu=403: %{!Dppc*: %{!Dmpc*: -Dppc403} } } \
+%{mcpu=505: %{!Dppc*: %{!Dmpc*: -Dmpc505} } } \
+%{mcpu=601: %{!Dppc*: %{!Dmpc*: -Dppc601} } } \
+%{mcpu=602: %{!Dppc*: %{!Dmpc*: -Dppc602} } } \
+%{mcpu=603: %{!Dppc*: %{!Dmpc*: -Dppc603} } } \
+%{mcpu=603e: %{!Dppc*: %{!Dmpc*: -Dppc603e} } } \
+%{mcpu=604: %{!Dppc*: %{!Dmpc*: -Dmpc604} } } \
+%{mcpu=750: %{!Dppc*: %{!Dmpc*: -Dmpc750} } } \
+%{mcpu=821: %{!Dppc*: %{!Dmpc*: -Dmpc821} } } \
+%{mcpu=860: %{!Dppc*: %{!Dmpc*: -Dmpc860} } }
+
+#undef SUBSUBTARGET_EXTRA_SPECS
+#define SUBSUBTARGET_EXTRA_SPECS \
+ { cpp_os_rtems,CPP_OS_RTEMS_SPEC }
It would avoid polluting other targets' spec with RTEMS details while it should
not make a difference for powerpc-rtems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19548
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-21
10:07 ---
unsigned long bn_add_words (unsigned long *rp, unsigned long *ap, unsigned long
*bp,int n)
{ unsigned long ret,i;
if (n = 0) return 0;
asm (
subq%2,%2 \n
.align 16 \n
1: movq(%4,%2,8),%0\n
adcq(%5,%2,8),%0\n
movq%0,(%3,%2,8)\n
leaq1(%2),%2\n
loop1b \n
sbbq%0,%0 \n
: +a(ret),+c(n),+r(i)
: r(rp),r(ap),r(bp)
: cc
);
return ret1;
}
again.
Probably bugzilla is mangling something.
Just go to .i file and search for bn_add_words ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug rtl-optimization/19560] New: Adding -g disables -foptimize-sibling-calls optimization in some cases
With the option -foptimize-sibling-calls tail recursion is
performed. Adding -g destroys this optimization. In my opinion,
adding compiler option -g should not change the behaviour of
the compiled program.
Environment:
System: SunOS rungner.nada.kth.se 5.9 Generic_117171-07 sun4u sparc
SUNW,Sun-Fire-280R
Architecture: sun4
host: sparc-sun-solaris2.9
build: sparc-sun-solaris2.9
target: sparc-sun-solaris2.9
configured with: /afs/.nada.kth.se/pkg/gcc/src/3.4.2/gcc-3.4.2/configure
--prefix=/pkg/gcc/3.4.2/os
How-To-Repeat:
Compile the following program:
/*
* In this function, it seems that tail recursion is performed both with
*
* gcc -foptimize-sibling-calls -S tail.c
*
* and with
*
* gcc -g -foptimize-sibling-calls -S tail.c
*
* using gcc 3.4.2 on a SPARC.
*/
void f(int n)
{
if(n 0)
f(--n);
}
/*
* In this function, it seems that tail recursion is performed with
*
* gcc -foptimize-sibling-calls -S tail.c
*
* but not with
*
* gcc -g -foptimize-sibling-calls -S tail.c
*
* using gcc 3.4.2 on a SPARC.
*/
void g(int n)
{
if(n 0)
f(--n);
return;
}
int main(int argc, char **argv)
{
f(10);
g(10);
}
(Preprocessor output is included below.)
For the function f(), the assembler output ends with
callf, 0
restore
.LL1:
nop
ret
restore
.LLFE2:
.size f, .-f
both with and without compiler option -g. For the function
g(), however, the assembler output ends with
callf, 0
restore
.LL3:
nop
ret
restore
.size g, .-g
if -g is *not* used, and with
callf, 0
nop
.LL3:
nop
ret
restore
.LLFE3:
.size g, .-g
if -g *is* used. And now the preprocessor output:
# 1 tail.c
# 1 built-in
# 1 command line
# 1 tail.c
# 27 tail.c
void f(int n)
{
if(n 0)
f(--n);
}
# 44 tail.c
void g(int n)
{
if(n 0)
f(--n);
return;
}
int main(int argc, char **argv)
{
f(10);
g(10);
}
--- Additional Comments From enge at nada dot kth dot se 2005-01-21 10:12
---
Fix:
I do not know of a fix.
--
Summary: Adding -g disables -foptimize-sibling-calls optimization
in some cases
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enge at nada dot kth dot se
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19560
[Bug fortran/19561] New: [gfortran] wrong code generation for pointers to derived types
When compiling the following code with current gfortan, the resulting executable produces the following output: number, derived = 2 number, simple = 1 number, simple = * The (IMO) correct output would be number, derived = 2 number, simple = 1 number, simple = 1 which is produced by most other compilers I tried. Only Intel ifc 8.0 and 8.1 produce the same output as gfortran. module simpleObj implicit none type objA private integer :: i end type objA interface new module procedure oaInit end interface interface print module procedure oaPrint end interface private public objA,new,print contains subroutine oaInit(oa,i) integer :: i type(objA) :: oa oa%i=i end subroutine oaInit subroutine oaPrint(oa) type(objA) :: oa print '(number, simple = ,i5)', oa%i end subroutine oaPrint end module simpleObj ! - module derivedObj use simpleObj implicit none type objB private integer :: i type(objA), pointer :: oa end type objB interface new module procedure obInit end interface interface print module procedure obPrint end interface private public objB,new,print,getOa contains subroutine obInit(ob,oa,i) integer :: i type(objA), target :: oa type(objB) :: ob ob%i=i ob%oa=oa end subroutine obInit subroutine obPrint(ob) type(objB) :: ob print '(number, derived = ,i5)', ob%i call print(ob%oa) end subroutine obPrint function getOa(ob) result(oa) type(objB),target :: ob type(objA), pointer :: oa oa=ob%oa end function getOa end module derivedObj ! - program test use simpleObj use derivedObj implicit none type(objA),target :: oa type(objB),target :: ob call new(oa,1) call new(ob,oa,2) call print(ob) call print(getOa(ob)) end program test ~/tmpgfortran -v test.f90 Driving: gfortran -v test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95 --with-gmp=/afs/mpa/data/martin/mygmp Thread model: posix gcc version 4.0.0 20050120 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=pentiumpro -auxbase test -version -o /tmp/ccZa4zwg.s GNU F95 version 4.0.0 20050120 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20050120 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc0LLrQq.o /tmp/ccZa4zwg.s GNU assembler version 2.14 (i686-pc-linux-gnu) using BFD version 2.14 20030612 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o -L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../.. /tmp/cc0LLrQq.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o /usr/lib/crtn.o ~/tmp./a.out number, derived = 2 number, simple = 1 number, simple = * -- Summary: [gfortran] wrong code generation for pointers to derived types Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug fortran/19561] [gfortran] wrong code generation for pointers to derived types
-- What|Removed |Added Keywords||wrong-code Known to fail||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug rtl-optimization/19560] Adding -g disables -foptimize-sibling-calls optimization in some cases
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-21 10:47 --- Fixed in GCC 3.4.3 by 2004-09-14 Richard Henderson [EMAIL PROTECTED] * sibcall.c (call_ends_block_p): Fix thinko finding the last real insn in a block. Thanks for the bug report. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19560
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 10:57 --- Created an attachment (id=8029) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8029action=view) Disable some expensive passes at -O1 I'm running a SPECint comparison between GCC-hammer-branch and mainline with the attached patch applied. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug libstdc++/19562] New: reverse_iterator comparison
This code does not compile:
#include map
using namespace std;
typedef mapint,int Map;
int main()
{
Map::reverse_iterator a;
Map::const_reverse_iterator b;
return a==b;
}
--
Summary: reverse_iterator comparison
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kunert at physik dot tu-dresden dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19562
[Bug libstdc++/19562] reverse_iterator comparison
--- Additional Comments From pcarlini at suse dot de 2005-01-21 11:34 --- *** This bug has been marked as a duplicate of 11729 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19562
[Bug libstdc++/11729] [DR280] no operator!= for const_reverse_iterator
--- Additional Comments From pcarlini at suse dot de 2005-01-21 11:34 --- *** Bug 19562 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||kunert at physik dot tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11729
[Bug target/19556] [4.0 Regression] ICE with -march=pentium-m (during bootstrap)
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21
11:38 ---
Looks like a reload problem (of course).
In the .lreg dump we have this:
(insn:HI 100 99 101 9 (set (reg/v/f:SI 64 [ all_ovr_obj ])
(reg/f:SI 87)) 41 {*movsi_1} (nil)
(nil))
In the .greg dump we get these reloads for insn 100:
Spilling for insn 100.
...
Spilling for insn 100.
...
Reloads for insn # 100
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 6 bp)
(const_int -28
[0xffe4]))
SSE_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (plus:SI (reg/f:SI 6 bp)
(const_int -28
[0xffe4]))
reload_reg_rtx: (reg/v/f:SI 21 xmm0 [orig:64 all_ovr_obj ] [64])
...
At the moment of the ICE we have this:
(insn 287 99 288 8 (set (reg/v/f:SI 21 xmm0 [orig:64 all_ovr_obj ] [64])
(reg/f:SI 6 bp)) 41 {*movsi_1} (nil)
(nil))
(insn 288 287 100 8 (set (reg/v/f:SI 21 xmm0 [orig:64 all_ovr_obj ] [64])
(plus:SI (reg/v/f:SI 21 xmm0 [orig:64 all_ovr_obj ] [64])
(const_int -28 [0xffe4]))) -1 (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 6 bp)
(const_int -28 [0xffe4]))
(nil)))
(insn:HI 100 288 101 8 (set (reg/v/f:SI 21 xmm0 [orig:64 all_ovr_obj ] [64])
(reg/v/f:SI 21 xmm0 [orig:64 all_ovr_obj ] [64])) 41 {*movsi_1} (nil)
(nil))
Why does reload reload an SImode register to an sse register?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19556
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-21 12:11 --- 0.9.7d crashes too. Please try it on your machines.If you have some amd64 computer. From the backtrace: ... 0x2ad71ecd bn_add_words+13: data16 0x2ad71ece bn_add_words+14: data16 0x2ad71ecf bn_add_words+15: nop ... this 'data' is from .align 16. Shouldn't it all be nop's ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug rtl-optimization/19464] [3.3/3.4/4.0 Regression] gcse causes poor register allocation
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 12:25 --- This can be fixed at the tree level without any gcse or ra hacking: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01462.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-15 21:04:44 |2005-01-21 12:25:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19464
[Bug other/19563] New: Makefiles don't handle configure --program-suffix
I just tried to abuse autoconf's --program-suffix feature (../configure --program-suffix=-4.0) to have gcc 3.4.x and 4.0 in the same directory without conflicts. Looks like the configure option is completely ignored -- the resulting binaries are named as usual. -- Summary: Makefiles don't handle configure --program-suffix Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i586-ark-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19563
Complex Numbers
Hello I have looked at the implementation of complex arithmetic in gcc. I see tree problems with naive formulas for multiplication and division that are currently in use. 1. Problems with special values. For example (infinity+ i*NaN)^2 should be (infinity + i*0) according to IEC 60559 and not (NaN + i*NaN). Please see the example code in Annex G. 2. If a is large but representable with a^2=infinity. We get (a+ i*a)^2=(NaN+i*infinity) with the naive formula but we want (0+i*infinity) 3. The are cancellation problems. For example if we use 3 digit decimal floating point arithmetic with a=4.02, b=4.00, c=4.02 and d=4.00 the exact result for the real part would be $ac-bd = 0.1604$. But with the naive formula we get a * c = 16.2, b * c = 16.0 and thus a*c - b* d = 0.2. This make a 25% error. The IEC 60559 standard deal only with problem 1 but not with the problems 2 and 3. According to Annex G the specifications (of IEC 60559) are not normative and therefore I think we should do better and use code that avoid all problems mentioned above. Perhaps we should provide the IEC 60599 code through the __STDC_IEC_559_COMPLEX__ pragma as suggested in Annex G. I have a solution to the problems describe above and I am willing (and hopefully able) to write a fix. How ever the resulting code would be about 2-3 times slower than the naive code. For example on a computer that has an fma machine instruction p=-b*d; r=fma(b,d,p); x=fma(a,c,p)-r; computes the real part avoiding cancellation, but this needs 4 operations where the naive formula needs only 2. p=-b*d; x=fma(a,c,p) So please tell me do you think we should switch to more accurate algorithms or would you prefer the old implementation? With best regards Andreas Klein Institute for Mathematics and Computer Science [EMAIL PROTECTED] University of Kassel Germany PS: I am better in math than in email. So please be patient if have chosen the wrong format or the wrong group.
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 12:39 --- (In reply to comment #15) I will note for the record that disabling local-alloc will resolve this problem. A patch for that is in the audit trail of another bug, for unrelated reasons: http://gcc.gnu.org/PR13776. It also happens to fix the particular problem in this bug report. I didn't test the source proposed in this bugreport, but the patch mentioned above (disabling of local-alloc) DOES NOT resolve the problem with the testcode proposed in bugreport http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549, and, though, it also doesn't fix the problem of compiling ffmpegs libavcodec/i386/dsputil_mmx.c, because that is the original, from which the testcode was extracted/simplified. So, either it is not the same bug (as marked by Andrew) or the problem was not resolved. And IMHO this shoul be perfectly valid, since the operands to the asm construction are all marked as m (!!!), so no registers should be needed for that! They are just memory operands!! And so I think this bug (or at least http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549) should NOT be marked as resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
Re: Complex Numbers
I have looked at the implementation of complex arithmetic in gcc. We are already aware of this issue, since you have already reported it ;) The relevant PR is middle-end/18902. Indeed, our plan involves enabling the (*already available*) algorithm due to Smith. There are still some open issues, however (see Depends on and blocks fields, for further details). As usual, patches are *welcome*, if prepared according to our (usual) rules and the necessary copyright assignment is in place. Paolo.
Re: Complex Numbers
Paolo Carlini wrote: We are already aware of this issue, since you have already reported it ;) The relevant PR is middle-end/18902. Forgot to add: for other issues, related in particular to multiplication, not only division, please file appropriate Bugzilla PRs. Thanks! Paolo.
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From uros at kss-loka dot si 2005-01-21 12:51 --- Similar problems as described in comment #2 happens for -mfpmath=sse -mno-80387. However, a patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01464.html is needed, otherwise compilation fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug rtl-optimization/19464] [3.3/3.4/4.0 Regression] gcse causes poor register allocation
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 12:51 --- With my patch I get almost perfect code for amd64: .globl f .type f, @function f: .LFB2: decl%edi je .L6 movlr5(%rip), %r9d movlr4(%rip), %r8d xorl%r10d, %r10d movlr3(%rip), %esi movlr2(%rip), %ecx movlr0(%rip), %edx movlr1(%rip), %eax .p2align 4,,7 .L4: addl%edx, %eax incl%r10d addl%eax, %ecx addl%ecx, %esi addl%esi, %r8d addl%r8d, %r9d addl%r9d, %edx cmpl%r10d, %edi jne .L4 movl%r9d, r5(%rip) movl%r8d, r4(%rip) movl%esi, r3(%rip) movl%ecx, r2(%rip) movl%edx, r0(%rip) movl%eax, r1(%rip) .L6: rep ; ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19464
[Bug fortran/19561] [gfortran] wrong code generation for pointers to derived types
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-01-21 13:03 --- Confirmed on Cygwin and RH9 In an attempt to reduce this a bit, I have produced a slightly more startling error: $ cat point.f90 module mpoint type :: mytype integer :: i end type mytype contains function get (a) result (b) type (mytype), target :: a type (mytype), pointer :: b b = a end function get end module mpoint program point use mpoint type (mytype), target :: x type (mytype), pointer :: y x = mytype (42) print *, get (x) end program point $ d:/irun/bin/gfortran -c -v point.f90 Using built-in specs. Configured with: ../gcc/configure --with-gmp=/usr/local --with- mpfr=/usr/local - -enable-languages=c,f95,c++ --prefix=/cygdrive/d/irun : (reconfigured) ../gcc/co nfigure --with-gmp=/usr/local --with-mpfr=/usr/local -- prefix=/cygdrive/d/irun - -with-gcc-version-trigger=/cygdrive/d/gcc-cvs/gcc/gcc/version.c --enable- languag es=c,c++,f95 --no-create --no-recursion : (reconfigured) ../gcc/configure -- with -gmp=/usr/local --with-mpfr=/usr/local --prefix=/cygdrive/d/irun --with-gcc- vers ion-trigger=/cygdrive/d/gcc-cvs/gcc/gcc/version.c --enable- languages=c,c++,f95 - -no-create --no-recursion Thread model: single gcc version 4.0.0 20050116 (experimental) /cygdrive/d/irun/libexec/gcc/i686-pc-cygwin/4.0.0/f951.exe point.f90 -quiet - du mpbase point.f90 -mtune=pentiumpro -auxbase point -version - o /cygdrive/c/DOCUME ~1/PAULTH~1/LOCALS~1/Temp/cc6mI8lv.s GNU F95 version 4.0.0 20050117 (experimental) (i686-pc-cygwin) compiled by GNU C version 3.3.1 (cygming special). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 point.f90: In function 'MAIN__': point.f90:16: internal compiler error: tree check: expected record_type or union _type or qual_union_type, have pointer_type in find_compatible_field, at tree.c: 5995 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug other/19563] Makefiles don't handle configure --program-suffix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 13:07 --- Is this just the Ada's programs that don't get transformed or all. If it is just Ada, then this is a dup of bug 864. Otherwise, this was fixed even longer before 3.4.0 by: 2001-11-08 Andreas Franck [EMAIL PROTECTED] * configure.in: Add AC_ARG_PROGRAM to support program name transformation with --program-prefix, --program-suffix and --program-transform-name. * configure: Regenerated. * Makefile.in (GCC_INSTALL_NAME, CPP_INSTALL_NAME, PROTOIZE_INSTALL_NAME, UNPROTOIZE_INSTALL_NAME, GCOV_INSTALL_NAME, GCCBUG_INSTALL_NAME, GCC_CROSS_NAME, CPP_CROSS_NAME, PROTOIZE_CROSS_NAME, UNPROTOIZE_CROSS_NAME): Handle program_transform_name the way suggested by autoconf. (GCC_TARGET_INSTALL_NAME): Define. (install-driver): Use the transformed target alias name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19563
[Bug tree-optimization/19038] [4.0 Regression] out of ssa causing loops to have more than one BB
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 13:18 --- No, tree-ssa-live is quite right. ivtmp.3_12 and ivtmp.3_20 are defined and live at some common statements, so they conflict: # BLOCK 1 # PRED: 0 [88.4%] (true,exec) 1 [89.0%] (dfs_back,false,exec) # ivtmp.3_12 = PHI 0(0), ivtmp.3_20(1); L8:; D.501_28 = __BLNK__.array1[ivtmp.3_12]; # __BLNK___11 = V_MAY_DEF __BLNK___2; *D.501_28 = 1.0e+0; ivtmp.3_20 = ivtmp.3_12 + 1; D.503_30 = D.457_4 - 1; D.504_31 = (unnamed type) D.503_30; D.505_32 = D.504_31 + 1; if (ivtmp.3_20 == D.505_32) goto L12; else goto L8; # SUCC: 2 [11.0%] (loop_exit,true,exec) 1 [89.0%] (dfs_back,false,exec) # BLOCK 2 # PRED: 1 [11.0%] (loop_exit,true,exec) L12:; D.497_22 = ivtmp.3_12 + 2; lsm_tmp.2_23 = (int4) D.497_22; # j_7 = V_MUST_DEF j_6; j = lsm_tmp.2_23; # SUCC: 3 [100.0%] (fallthru) Between ivtmp.3_20 = ivtmp.3_12 + 1; and D.497_22 = ivtmp.3_12 + 2; both versions of ivtmp.3 are live. I have not looked at what causes this, but IMOH all passes should avoid letting induction variables escape a loop. Interesting note: I think D.497_22 = ivtmp.3_12 + 2; could be replaced with D.497_22 = ivtmp.3_20 + 1; which would fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug tree-optimization/19038] [4.0 Regression] out of ssa causing loops to have more than one BB
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-01-21 13:22 --- Subject: Re: [4.0 Regression] out of ssa causing loops to have more than one BB No, tree-ssa-live is quite right. ivtmp.3_12 and ivtmp.3_20 are defined and live at some common statements, so they conflict: # BLOCK 1 # PRED: 0 [88.4%] (true,exec) 1 [89.0%] (dfs_back,false,exec) # ivtmp.3_12 = PHI 0(0), ivtmp.3_20(1); L8:; D.501_28 = __BLNK__.array1[ivtmp.3_12]; # __BLNK___11 = V_MAY_DEF __BLNK___2; *D.501_28 = 1.0e+0; ivtmp.3_20 = ivtmp.3_12 + 1; D.503_30 = D.457_4 - 1; D.504_31 = (unnamed type) D.503_30; D.505_32 = D.504_31 + 1; if (ivtmp.3_20 == D.505_32) goto L12; else goto L8; # SUCC: 2 [11.0%] (loop_exit,true,exec) 1 [89.0%] (dfs_back,false,exec) # BLOCK 2 # PRED: 1 [11.0%] (loop_exit,true,exec) L12:; D.497_22 = ivtmp.3_12 + 2; lsm_tmp.2_23 = (int4) D.497_22; # j_7 = V_MUST_DEF j_6; j = lsm_tmp.2_23; # SUCC: 3 [100.0%] (fallthru) Between ivtmp.3_20 = ivtmp.3_12 + 1; and D.497_22 = ivtmp.3_12 + 2; both versions of ivtmp.3 are live. I have not looked at what causes this, but IMOH all passes should avoid letting induction variables escape a loop. There's not much to avoid -- the iv is simply used outside of the loop, and we cannot do anything about it. Interesting note: I think D.497_22 = ivtmp.3_12 + 2; could be replaced with D.497_22 = ivtmp.3_20 + 1; which would fix this problem. I think this is how it is immediately after ivopts (if not, it would be a bug); but dom performs this replacement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug tree-optimization/19038] [4.0 Regression] out of ssa causing loops to have more than one BB
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 13:27 --- Correctemundo Zdenek! Before dom3: # BLOCK 2 # PRED: 1 [100.0%] (fallthru) 2 [89.0%] (dfs_back,false,exec) # ivtmp.3_12 = PHI 0(1), ivtmp.3_20(2); # __BLNK___2 = PHI __BLNK___8(1), __BLNK___11(2); L8:; D.498_25 = (unnamed type) lsm_tmp.2_14; D.499_26 = ivtmp.3_12 + D.498_25; D.500_27 = D.499_26 + ; D.501_28 = __BLNK__.array1[D.500_27]; ruatmp.9_29 = D.501_28; # __BLNK___11 = V_MAY_DEF __BLNK___2; *ruatmp.9_29 = 1.0e+0; ivtmp.3_20 = ivtmp.3_12 + 1; D.503_30 = D.457_4 - lsm_tmp.2_14; D.504_31 = (unnamed type) D.503_30; D.505_32 = D.504_31 + 1; if (ivtmp.3_20 == D.505_32) goto L12; else goto L8; # SUCC: 3 [11.0%] (loop_exit,true,exec) 2 [89.0%] (dfs_back,false,exec) # BLOCK 3 # PRED: 2 [11.0%] (loop_exit,true,exec) # ivtmp.3_24 = PHI ivtmp.3_20(2); L12:; D.496_21 = (unnamed type) lsm_tmp.2_14; D.497_22 = ivtmp.3_24 + D.496_21; lsm_tmp.2_23 = (int4) D.497_22; lsm_tmp.2_19 = lsm_tmp.2_23; # j_7 = V_MUST_DEF j_6; j = lsm_tmp.2_19; # SUCC: 4 [100.0%] (fallthru) After dom3: # BLOCK 2 # PRED: 1 [100.0%] (fallthru) 2 [89.0%] (dfs_back,false,exec) # ivtmp.3_12 = PHI 0(1), ivtmp.3_20(2); # __BLNK___2 = PHI __BLNK___8(1), __BLNK___11(2); L8:; D.498_25 = 1; D.499_26 = ivtmp.3_12 + 1; D.500_27 = ivtmp.3_12; D.501_28 = __BLNK__.array1[ivtmp.3_12]; ruatmp.9_29 = D.501_28; # __BLNK___11 = V_MAY_DEF __BLNK___2; *D.501_28 = 1.0e+0; ivtmp.3_20 = ivtmp.3_12 + 1; D.503_30 = D.457_4 - 1; D.504_31 = (unnamed type) D.503_30; D.505_32 = D.504_31 + 1; if (ivtmp.3_20 == D.505_32) goto L12; else goto L8; # SUCC: 3 [11.0%] (loop_exit,true,exec) 2 [89.0%] (dfs_back,false,exec) # BLOCK 3 # PRED: 2 [11.0%] (loop_exit,true,exec) # ivtmp.3_24 = PHI ivtmp.3_20(2); L12:; D.496_21 = 1; D.497_22 = ivtmp.3_12 + 2; lsm_tmp.2_23 = (int4) D.497_22; lsm_tmp.2_19 = lsm_tmp.2_23; # j_7 = V_MUST_DEF j_6; j = lsm_tmp.2_23; # SUCC: 4 [100.0%] (fallthru) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug tree-optimization/19038] [4.0 Regression] tree-ssa causing loops to have more than one BB
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 13:28 --- Not an out-of-ssa problem. This is a DOM problem. -- What|Removed |Added Summary|[4.0 Regression] out of ssa |[4.0 Regression] tree-ssa |causing loops to have more |causing loops to have more |than one BB |than one BB http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug c/19435] spurious warnings with nested array constructors
--- Additional Comments From mmikucionis at gmail dot com 2005-01-21 13:37
---
I have very similar situation but with even worse results:
struct foo {
int i;
char* s[];
} arr[] = {
{
1, { first, second }
},
{
2, { third, fourth }
}
};
gcc (GCC) 3.3.5 (Debian 1:3.3.5-6) and gcc-3.4 (GCC) 3.4.4 20041218 (prerelease)
(Debian 3.4.3-7) say the following:
$ gcc-3.3 struct.cc
struct.cc:11: internal compiler error: in tree_low_cst, at tree.c:3255
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
URL:file:///usr/share/doc/gcc-3.3/README.Bugs.
gcc 2.95.4 says the following:
$ gcc-2.95 struct.cc
struct.cc:11: excess elements in aggregate initializer
struct.cc:11: excess elements in aggregate initializer
I am not sure whether the code is correct according to standards,
but gcc should not break there :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19435
[Bug c++/19564] New: -Wparentheses and other warnings: g++ is less sensitive than gcc
g++ generates less warnings when using -Wparentheses than gcc. For instance gcc warns about if (a0 b0) ... (warning: suggest parentheses around comparison in operand of ) but g++ does not. And gcc warns about char a = 1024; (warning: overflow in implicit constant conversion) but g++ does not. -- Summary: -Wparentheses and other warnings: g++ is less sensitive than gcc Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19564
[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 13:46 --- Mark, can we move the milestone on this one please? There is no way this will be fixed for GCC 4.0. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15559
[Bug middle-end/17549] [4.0 Regression] 35% increase in codesize with C code
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 13:47 --- (From update of attachment 7380) already applied -- What|Removed |Added Attachment #7380 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From falk at debian dot org 2005-01-21 13:55 --- (In reply to comment #17) And IMHO this shoul be perfectly valid, since the operands to the asm construction are all marked as m (!!!), so no registers should be needed for that! Huh? The memory operands are not at a compile time constant address, so of course you need a register to hold them. Of course, you need only one register for all of them, but you explicitely disallowed gcc to discover that by specifying -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug middle-end/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 14:00 --- For the test case from comment #1 I get the following for AMD64: GCC 4.0 (20050121): textdata bss dec hex filename 24689 0 0 246896071 t.O2.o 20728 0 0 2072850f8 t.Os.o GCC 3.3-SUSE (pre 3.3.5 20040809 hammer-branch) 22682 0 0 22682589a t.O2.o 21281 0 0 212815321 t.Os.o and for i686: GCC 4.0 (20050121): 24064 0 0 240645e00 t.O2.o 19479 0 0 194794c17 t.Os.o GCC 3.3-SUSE (pre 3.3.5 20040809 hammer-branch) -m32 19646 0 0 196464cbe t.O2.o 17713 0 0 177134531 t.Os.o So I am seeing a 10% code size increase at -O2 for GCC 4.0 compared to the hammer-branch based GCC 3.3. GCC 3.3 was the best score we had for this so far. The 35% from the subject is quite exaggerated, so I have adjusted it. (FWIW, the GCC 4.0 I tested has my patch for PR19454 applied, which makes quite a difference for -m32 -O2, but not for -Os...). -- What|Removed |Added Summary|[4.0 Regression] 35%|[4.0 Regression] 10% |increase in codesize with C |increase in codesize with C |code|code compared to GCC 3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug middle-end/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 14:02 --- (FWIW, the GCC 4.0 I tested has my patch for PR19454 applied, which makes quite a difference for -m32 -O2, but not for -Os...). That'd be PR19464 ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug tree-optimization/18219] [4.0 Regression] gcc-4.0.0 bloats code by 31%
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 14:04 --- This actually looks like a duplicate of PR19038 now. -- What|Removed |Added BugsThisDependsOn||19038 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-21 14:06 --- Zdenek, is this still a regression, or are your suggestions from comment #12 only enhancements? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 14:10 --- (In reply to comment #18) Huh? The memory operands are not at a compile time constant address, so of course you need a register to hold them. Of course, you need only one register for all of them, but you explicitely disallowed gcc to discover that by specifying -O0. Sure, one, sorry. But problem is the Bug 19549 testcode doesn't compile AT ALL. I.e., not only with -O0, but also with -O1, -O2, or -O3. It simply doesn't compile under any circumstances. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug c++/19564] -Wparentheses does not work with the C++ front-end
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 14:11 --- (In reply to comment #0) g++ generates less warnings when using -Wparentheses than gcc. For instance gcc warns about if (a0 b0) ... This because this warning is only in the C front-end. Please file the overflow in implicit constant conversion warning into a different bug. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-01-21 14:11:16 date|| Summary|-Wparentheses and other |-Wparentheses does not work |warnings: g++ is less |with the C++ front-end |sensitive than gcc | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19564
[Bug c++/19564] -Wparentheses does not work with the C++ front-end
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
14:12 ---
Note here is the testcase:
int f(int a, int b)
{
if (a0 b0) /* { dg-warning } */
return 210;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19564
[Bug c/19435] spurious warnings with nested array constructors
--- Additional Comments From mmikucionis at gmail dot com 2005-01-21 14:31 --- my last comment was close to this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18926 sorry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19435
[Bug c++/19565] New: g++ does not warn about overflow in conversion but gcc does
g++ does not warn if there occurs an overflow in conversion. For instance, gcc does not warn about char a = 1024; but gcc does. -- Summary: g++ does not warn about overflow in conversion but gcc does Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19565
[Bug middle-end/19551] [3.4/4.0 Regression] LAPACK routine claic1.f bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 14:32 --- Hmm, adding -fno-builtin fixes the failure, maybe this is libcall problem then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug c/19435] spurious warnings with nested array constructors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 14:36 --- (In reply to comment #2) I have very similar situation but with even worse results: The C++ problem is recorded in a different bug (that might have been my fault for not testing the C++ front-end), see PR 18327. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19435
[Bug c++/19565] g++ does not warn about overflow in conversion but gcc does
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 14:38 --- Confirmed. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-01-21 14:38:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19565
[Bug target/19548] [3.4/4.0 regression] RTEMS CPP specs not merged from 3.2/3.2 branches
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 14:42 --- (In reply to comment #3) (In reply to comment #2) commit was not there so I would assume this could clarify as obvious. OK, thanks. What do you think about moving CPP_OS_RTEMS_SPEC into rs6000/rtems.h, i.e. about a applying this patch to gcc-4.0: I would say this is better. Rember you are a RTEMS maintainer so you can approve it yourself but remember I have no say, I am just a person who likes to go through all the bug reports and help out. Also if this gets applied to 4.0, please also try to get it applied for 3.4.0 also since this is 3.4 regression too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19548
[Bug fortran/19561] [gfortran] wrong code generation for pointers to derived types
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-21 14:48 --- Testcase invokes undefined behaviour. http://gcc.gnu.org/ml/fortran/2005-01/msg00234.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug fortran/19561] [gfortran] wrong code generation for pointers to derived types
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-21 14:57 --- My bad, this is in fact legal and well defined. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug fortran/19561] [gfortran] wrong code generation for pointers to derived types
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-21 14:58:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19561
[Bug target/19549] Register allocation problem in inline asm on x86.
--- Additional Comments From falk at debian dot org 2005-01-21 15:05 --- Reporter says in PR 11203 this does happen even at -O2, so it's not a duplicate of PR 11203. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549
[Bug target/19549] Register allocation problem in inline asm on x86.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 15:15 --- It still a dup of bug 11203 and here is why, the a gets placed in different register for the inline-asm at -O0 but -O1 and above, we use the same register/offset but PR 11203 has a testcase where it does not compile at -O0 to -O3 but that is because the memory operands share in common areas. Anyways this inline-asm is useless as the operands are all the same which is why it works at -O1 but not at -O0 and you just ran out of registers on x86 because we don't do any optimization at all at -O0. *** This bug has been marked as a duplicate of 11203 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 15:15 --- *** Bug 19549 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
15:22 ---
This is a real bug, but easily fixed, and (I think) without breaking ABI.
The problem is in basic_string.h, where it says
struct _Rep : _Rep_base
{
// Types:
typedef typename _Alloc::template rebindchar::other _Raw_bytes_alloc;
Technically this should be rebind_Rep::other. Of course then
it's not really a raw-bytes allocator, but we have no need for a
raw_bytes allocator. We need an allocator of space for a _Rep with
room for raw bytes at the end. Remaining to fix is to change the name
in the very few places where it's used, and to change the argument to
allocate() (and deallocate) so that it ends up allocating the right
number of bytes.
Probably a better fix would be to use rebindT::other, where
T is the most strictly-aligned of members of _Rep, i.e. size_type
or _Atomic_word. This is easily determined as the union of the
two:
union { _Atomic_word w; size_type s; } _Alloc_unit;
typedef typename _Alloc::template rebind_Alloc_unit::other _Raw_alloc;
and then scale the argument to allocate() by the size of _Alloc_unit.
Fortunately, the required / sizeof(_Alloc_unit) may (will?) be
weakened to 2 or 4 on all real targets.
Either way, then, it's up to __gnu_cxx::array_allocatorchar_type,
array_type to make sure its argument is aligned properly. If it
can't, that's a (more serious) bug in that template. The test case
2.cc had better leave enough room in the byte array for that
alignment adjustment, which it does not quite do, I think, on 64-bit
targets.
Of course all this means this bug is not really an enhancement,
but bugzilla won't let me fix that.
--
What|Removed |Added
CC||ncm-nospam at cantrip dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug libstdc++/19562] reverse_iterator comparison
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-21 15:33 ---
Subject: Re: New: reverse_iterator comparison
kunert at physik dot tu-dresden dot de [EMAIL PROTECTED] writes:
| This code does not compile:
|
| #include map
| using namespace std;
|
| typedef mapint,int Map;
|
| int main()
| {
| Map::reverse_iterator a;
| Map::const_reverse_iterator b;
| return a==b;
Known defect. Omission from the committee.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19562
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
15:37 ---
Hmm, it's a little more complicated than I said, although it might be
academic. There's an implicit assumption in the code that any type
on which basic_string might be instantiated has no stricter alignment
than _Rep itself. But that's a different bug. Probably the right way
to fix it is to replace the first member of _Rep with an anonymous union:
size_type _M_length;
becomes
union { size_type _M_length; _Some_big_aligned_type _M_alignment_dummy; };
I don't know if gcc supplies a built-in typedef for that. Without
checking, I think tr1 must do. I believe this can also be done
without breaking ABI on any actual target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pcarlini at suse dot de 2005-01-21 15:41 --- Thanks Nathan, I will implement what you are suggesting. The last issue, actually is filed as libstdc++/8670 and in the audit trail we agreed to fix it using a suited __attribute__(aligned), which however, doesn't work correctly at the moment (we have already a few open PRs about this). Indeed, I'd rather prefer fixing the two problems separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug target/19556] [4.0 Regression] ICE with -march=pentium-m (during bootstrap)
--- Additional Comments From arend dot bayer at web dot de 2005-01-21 15:43 --- Subject: Re: [4.0 Regression] ICE with -march=pentium-m (during bootstrap) I verified it still ICEs as of today (2005-01-21). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19556
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pcarlini at suse dot de 2005-01-21 15:43 --- By the way, I understand that tr1/aligned_storage co facilities cannot be directly used for implementing the current std, since we cannot pollute the std namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
-- What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug middle-end/19551] [3.4/4.0 Regression] LAPACK routine claic1.f bug
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-21 15:46 --- -fno-builtin only matters in not adding pure attribute to csqrtf. If you start the #5 testcase with _Complex float csqrtf(_Complex float) __attribute__((pure)); instead, it fails even with -fno-builtin. Reproduced on i386-redhat-linux, looking into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-01-21 15:49 ---
OK, sorry, the Bug 19549 testcode passes with -O1 and above, but the original,
that it was stripped from (maybe too much stripped) doesn't:
-- test2.c -
extern const unsigned char ff_h263_loop_filter_strength[32];
static const unsigned long long ff_pb_FC __attribute__((used)) __attribute__
((aligned(8))) = 0xFCFCFCFCFCFCFCFCULL;
void h263_h_loop_filter_mmx(unsigned char *src, int stride, int qscale){
const int strength= ff_h263_loop_filter_strength[qscale];
unsigned long long temp[4] __attribute__ ((aligned(8)));
unsigned char *btemp= (unsigned char *)temp;
src -= 2;
asm volatile(
: +m (temp[0]),
+m (temp[1]),
+m (temp[2]),
+m (temp[3])
: g (2*strength), m(ff_pb_FC)
);
asm volatile(
: =m (*(unsigned int*)(src + 0*stride)),
=m (*(unsigned int*)(src + 1*stride)),
=m (*(unsigned int*)(src + 2*stride)),
=m (*(unsigned int*)(src + 3*stride)),
=m (*(unsigned int*)(src + 4*stride)),
=m (*(unsigned int*)(src + 5*stride)),
=m (*(unsigned int*)(src + 6*stride)),
=m (*(unsigned int*)(src + 7*stride))
);
}
Or do you consider this also invalid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug target/19549] Register allocation problem in inline asm on x86.
--- Additional Comments From falk at debian dot org 2005-01-21 15:50 --- (In reply to comment #3) It still a dup of bug 11203 and here is why, the a gets placed in different register for the inline-asm at -O0 but -O1 and above, we use the same register/offset but PR 11203 has a testcase where it does not compile at -O0 to -O3 but that is because the memory operands share in common areas. Anyways this inline-asm is useless as the operands are all the same which is why it works at -O1 I can't quite follow. The reporter says this test case does *not* compile at -O1. In my opinion, gcc should be able to compile this asm at -O1 and above. Maybe somebody else can comment on this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549
[Bug c++/14479] enum definition in template class with template methods causes error.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-21 16:03 --- Patch for 3.4 and 4.0 submitted: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01491.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14479
[Bug c++/19487] [3.3/3.4/4.0 Regression] map with a class template + method template fails to compile.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-21 16:04 --- Patch for 3.4 and 4.0 submitted: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01491.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19487
[Bug c/19566] New: x86_64 - inconsistent choice of parameter passing method for 16 byte struct
The x86_64 compiler (verified in gcc 3.4.3, configured for
x86_64-redhat-linux)
chooses a different parameter passing method when passing a struct value,
depending upon whether a contained 16 bit bit field is declared as either
an 'int' or a 'short int'.
Given the following test case:
typedef struct shared_ptr_struct
{
unsigned long phase : 48;
unsigned int thread : 16;
void *addr;
} shared_ptr_t;
int y;
shared_ptr_t sp = {1, 2, y};
int
get_thread (shared_ptr_t p)
{
return p.thread;
}
int
main() {
int t = get_thread (sp);
return t;
}
A value of this type will be passed in two registers:
typedef struct shared_ptr_struct
{
unsigned long phase : 48;
unsigned short thread : 16;
void *addr;
} shared_ptr_t;
movqsp(%rip), %rdi
movqsp+8(%rip), %rsi
callget_thread
but a value of this type will be passed on the stack:
typedef struct shared_ptr_struct
{
unsigned long phase : 48;
unsigned int thread : 16;
void *addr;
} shared_ptr_t;
movqsp(%rip), %rax
movq%rax, (%rsp)
movqsp+8(%rip), %rax
movq%rax, 8(%rsp)
callget_thread
Is there anything about the ABI or C language definition
that dictates the difference in choice of parameter value passing method,
or should both struct definitions lead to the same choice of
parameter passing method?
Assuming these two declarations should pass a value of type shared_ptr_t
in the same fashion, I think the error originates in classify_argument in
config/i386/i386.c:
static int
classify_argument (enum machine_mode mode, tree type,
enum x86_64_reg_class classes[MAX_CLASSES], int
bit_offset)
{
HOST_WIDE_INT bytes =
(mode == BLKmode) ? int_size_in_bytes (type) : (int) GET_MODE_SIZE
(mode);
int words = (bytes + (bit_offset % 64) / 8 + UNITS_PER_WORD - 1) /
UNITS_PER_WORD;
when the thread field is declared as 'short', the mode will be HImode.
However,
if thread is declared as type 'int', the mode will be SImode. In the 'int'
case
the value for bytes is 4, and the value for words is 2, because threads is
not
aligned on a 32 bit boundary. Eventually, the logic will return here:
/* Misaligned fields are always returned in memory. */
if (bit_offset % mode_alignment)
return 0;
which tells the caller that the type of interest must be passed in memory
(on the stack) rather than in a register.
It looks as if either classify_argument is using the wrong computation for
the value of 'bytes', or earlier in the declaration of the processing of
'threads' when declared as an 'int', the compiler should use the smallest
sized
integer type that will accommodate the field (ie, a short int).
Also posted to the gcc mailing list:
http://gcc.gnu.org/ml/gcc/2005-01/msg01221.html
--
Summary: x86_64 - inconsistent choice of parameter passing method
for 16 byte struct
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19566
[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-21 16:07 --- Experimenting with SRA inside loop together with cleanup passes after cunroll/sra didn't reveal anything good - even with loop cfg_cleanup patched in. See thread starting at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01315.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18754
[Bug middle-end/19551] [3.4/4.0 Regression] LAPACK routine claic1.f bug
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-21 16:13
---
Simplified testcase:
extern void abort ();
__attribute__((pure)) _Complex float
foo (int x)
{
_Complex float r;
__real r = x + 1;
__imag r = x - 1;
return r;
}
void
bar (float *f)
{
*f = foo (5);
}
int
main (void)
{
float f;
bar (f);
if (f != 6.0)
abort ();
return 0;
}
Likely the culprit is in libcall_dead_p.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug other/19563] Makefiles don't handle configure --program-suffix
--- Additional Comments From bero at arklinux dot org 2005-01-21 16:19 --- It's not just ada, it's everything including gcc and g++ Looks like it reappeared somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19563
[Bug libstdc++/19510] [3.4 only] Uninitialized pointers in iterators
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21 16:22 --- Subject: Bug 19510 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-21 16:21:40 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_list.h stl_tree.h libstdc++-v3/testsuite/23_containers/map/operators: 1_neg.cc libstdc++-v3/testsuite/23_containers/set/operators: 1_neg.cc Log message: PR libstdc++/19510 * include/bits/stl_list.h (_List_iterator): Initialize _M_node in constructor. (_List_const_iterator): Likewise. * include/bits/stl_tree.h (_Rb_tree_iterator): Likewise. (_Rb_tree_const_iterator): Likewise. * testsuite/23_containers/map/operators/1_neg.cc: Adjust line numbers. * testsuite/23_containers/set/operators/1_neg.cc: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.2224.2.210r2=1.2224.2.211 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_list.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.34.4.4r2=1.34.4.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_tree.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.30.4.4r2=1.30.4.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3.4.1r2=1.3.4.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/set/operators/1_neg.cc.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3.4.1r2=1.3.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19510
[Bug libstdc++/19510] [3.3 only] Uninitialized pointers in iterators
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-21 16:23 --- Regtesting patch for 3.3 branch. -- What|Removed |Added Keywords|diagnostic, monitored | Summary|[3.4 only] Uninitialized|[3.3 only] Uninitialized |pointers in iterators |pointers in iterators http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19510
[Bug c++/19555] [4.0 Regression] specialized in the wrong namespace causes an ICE
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-21 16:25 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-21 16:25:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19555
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From falk at debian dot org 2005-01-21 16:33 --- (In reply to comment #21) Or do you consider this also invalid? It doesn't seem invalid to me. But it is basically impossible to write the register allocator such that it finds a register allocation for every situation where it's theoretically possible. So this is unlikely to get fixed in a reliable way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
16:39 ---
I agree that 8670 is a separate bug.
The referenced test 2.cc can be made to fail more reliably with
the following changes:
First, leave enough space for alignment adjustments, even on 128-bit
machines:
- typedef std::tr1::arraychar_type, 32 array_type;
+ typedef std::tr1::arraychar_type, 256 array_type;
Then, make sure extern_array itself is aligned more or less predictably.
- array_type extern_array;
+ union
+ {
+ array_type extern_array; size_t sdummy; double ddummy; char* pdummy;
+ };
Finally, make sure the storage passed to the allocator is misaligned:
- allocator_type a(extern_array);
+ allocator_type a(extern_array[1]);
I don't know how many other tests should be adjusted similarly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug target/19566] x86_64 - inconsistent choice of parameter passing method for 16 byte struct
--- Additional Comments From gary at intrepid dot com 2005-01-21 16:40 --- change from bug/c to bug/target -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19566
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 16:48 --- (In reply to comment #22) It doesn't seem invalid to me. But it is basically impossible to write the register allocator such that it finds a register allocation for every situation where it's theoretically possible. So this is unlikely to get fixed in a reliable way. OK, I guess I fixed the code in the ffmpeg to help gcc in the compilation a bit (I hope it will be accepted). So consider the above code rather as another code for testing, if occasionally, sometimes the problem gets resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 16:49 --- A build with GCC CVS LAST_UPDATED Fri Jan 21 03:20:28 UTC 2005 also fails in the same way. I don't have a pressing need to get this fixed, as my bootstrap-test needs are covered by native tools, but if wanted, I can dig up details, for example a tarball with the failing objects. Anyway, I did some digging myself. Apparently the failing link calls /usr/ccs/bin/ld, despite gcc otherwise using the newly built ld! Could it be that --with-gnu-as --with-gnu-ld is actually required also in a combined tree? (If so, there's a consistency bug. If not, it's a collect2 bug.) But maybe this is a red herring. To repeat the problem, I think a machine with no GNU tools installed is required, and maybe also required to start the build with gcc-2.95.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:09 --- Following up on comment #18, no GNU ld *is* used, it's just that adding -print-prog-name=ld to the failing link says /usr/ccs/bin/ld. An otherwise harmless bug, likely a WONTFIX. :-) But that's another bug. (There is no other ld in the newly build search path; what's used is the link collect-ld, which points to ../ld/ld-new.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:11 --- (Oops, I meant comment #15 in comment #16. It's my bug list that's 18. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21 17:12 --- I'm going to go a step further and mark this INVALID. Since we already do the right thing at -Os, and there's no evidence that we're actually generating slower code at -O2, I'm not worried about this issue. If there's evidence that the code we're generating is slower than with a previous compiler, post assembly code and timing information that shows that. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15559
[Bug rtl-optimization/5738] GCSE missed optimization: common condition instructions
-- Bug 5738 depends on bug 15559, which changed state. Bug 15559 Summary: [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15559 What|Old Value |New Value Status|ASSIGNED|NEW Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5738
[Bug other/16996] [meta-bug] code size improvements
-- Bug 16996 depends on bug 15559, which changed state. Bug 15559 Summary: [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15559 What|Old Value |New Value Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996
[Bug libstdc++/19567] New: dynamic_cast failure in dlopen-ed shared object
Please note this is not a duplicate of #4993, because I am using RTLD_GLOBAL and -Wl,-E. This test project demonstatrates a problem when using dynamic_cast from inside a shared object to attempt to convert a base class (interface) to a derived class (another interface) whose definitions are in header files shared between the application and the shared object. When casting from a base class to the derived class from inside the main executable, dynamic_cast works as expected and returns a non null pointer. However, from inside of the dlopen-ed shared library, the dynamic_cast function incorrectly returns zero. Attachment will follow. -- Summary: dynamic_cast failure in dlopen-ed shared object Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daveregs at rsaisp dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19567
[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-21 17:27 --- A build with GCC CVS LAST_UPDATED Fri Jan 21 03:20:28 UTC 2005 also fails in the same way. I don't have a pressing need to get this fixed, as my bootstrap-test needs are covered by native tools, but if wanted, I can dig up details, for example a tarball with the failing objects. I agree, this is not really urgent. Very few people do combined builds on SPARC/Solaris. I personally always specify both --with-as and --with-gnu-as when I use the GNU tools because I've had my share of problems too (although never this one, IIRC the build aborts earlier). Anyway, I did some digging myself. Apparently the failing link calls /usr/ccs/bin/ld, despite gcc otherwise using the newly built ld! Could it be that --with-gnu-as --with-gnu-ld is actually required also in a combined tree? (If so, there's a consistency bug. If not, it's a collect2 bug.) But maybe this is a red herring. OK, I've already run into something like that: although you specify both --with-gnu-as and --with-gnu-ld and GNU as and ld are first in the PATH, the Sun tools are nevertheless used at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21 17:28 --- m68k is not a primary or secondary platform; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/5362] Undocumented target options
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21 17:29 --- This will never be a release-critical issue; removing the target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
[Bug libstdc++/19567] dynamic_cast failure in dlopen-ed shared object
--- Additional Comments From daveregs at rsaisp dot com 2005-01-21 17:29 --- Created an attachment (id=8032) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8032action=view) Example program that demonstrates the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19567
[Bug libstdc++/19567] dynamic_cast failure in dlopen-ed shared object
--- Additional Comments From daveregs at rsaisp dot com 2005-01-21 17:30 --- Tested on fedora core 2 and 3, results are the same. more info: fc2: gcc version 3.3.3 20040412 Works on windows 3.4.2 (mingw-special) most likely because of the lack of support for weak symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19567
