[Bug target/22134] [4.1 Regression] vf_hue.c:54: internal compiler error: in final_scan_insn, at final.c:2419
--- Additional Comments From uros at kss-loka dot si 2005-06-22 06:08 --- Uh, it was a cut-n-pasto... -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||06/msg01759.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22134
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From uros at kss-loka dot si 2005-06-22 07:02
---
As this bug is getting a bit confused, I have summarised testcases below:
--cut here--
#include mmintrin.h
__m64 moo_1 (int i)
{
__m64 tmp = _mm_cvtsi32_si64 (i);
return tmp;
}
__m64 moo_2 (__m64 mmx1)
{
__m64 mmx2 = _mm_unpacklo_pi8 (mmx1, mmx1);
return mmx2;
}
void moo_3 (__m64 i, unsigned int *r)
{
unsigned int tmp = __builtin_ia32_vec_ext_v2si (i, 0);
*r = tmp;
}
--cut here--
I think that the problems described were fixed by PR target/21981. With a patch
from comment #20, 'gcc -O2 -msse3' produces following asm:
moo_1:
pushl %ebp
movl%esp, %ebp
movd8(%ebp), %mm0
popl%ebp
ret
moo_2:
pushl %ebp
punpcklbw %mm0, %mm0
movl%esp, %ebp
popl%ebp
ret
moo_3:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movd%mm0, (%eax)
emms
popl%ebp
ret
I have checked, that there is no SSE instructions present for any of testcases
for -mmmx, -msse, -msse2 and -msse3. I suggest to close this bug as fixed and
eventually open a new bug with new testcases.
Regarding emms in moo_3: As the output of moo_3 () is _not_ a mmx register, FPU
mode should be switched to 387 mode before function exit. (In proposed patch,
this could be overriden by -mno-80387 to get rid of all emms insns.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent
--- Additional Comments From uros at kss-loka dot si 2005-06-22 10:14
---
Just for fun, I have compiled the testcase with MMX/x87 mode switching patch
included, to check MMX vector extensions. This little patch is needed to enable
MMX vector extensions (only MMX vector add expander is shown):
diff -upr /export/home/uros/gcc-back/gcc/config/i386/i386.h i386/i386.h
--- /export/home/uros/gcc-back/gcc/config/i386/i386.h 2005-06-08
07:05:22.0 +0200
+++ i386/i386.h 2005-06-22 10:41:31.0 +0200
@@ -843,7 +845,8 @@ do {
\
/* ??? No autovectorization into MMX or 3DNOW until we can reliably
place emms and femms instructions. */
-#define UNITS_PER_SIMD_WORD (TARGET_SSE ? 16 : UNITS_PER_WORD)
+#define UNITS_PER_SIMD_WORD\
+(TARGET_SSE ? 16 : TARGET_MMX ? 8 : UNITS_PER_WORD)
#define VALID_FP_MODE_P(MODE) \
((MODE) == SFmode || (MODE) == DFmode || (MODE) == XFmode \
diff -upr /export/home/uros/gcc-back/gcc/config/i386/mmx.md i386/mmx.md
--- /export/home/uros/gcc-back/gcc/config/i386/mmx.md 2005-04-20
21:56:15.0 +0200
+++ i386/mmx.md 2005-06-22 11:00:35.0 +0200
@@ -553,6 +553,13 @@
;;
;
+(define_expand addmode3
+ [(set (match_operand:MMXMODEI 0 register_operand )
+ (plus:MMXMODEI (match_operand:MMXMODEI 1 nonimmediate_operand )
+ (match_operand:MMXMODEI 2 nonimmediate_operand )))]
+ TARGET_MMX
+ ix86_fixup_binary_operands_no_copy (PLUS, MODEmode, operands);)
+
(define_insn mmx_addmode3
[(set (match_operand:MMXMODEI 0 register_operand =y)
(plus:MMXMODEI
After that, the testcase from description is compiled to (with -fomit-frame-
pointer):
test:
movqw, %mm0
paddw %mm0, %mm0
movq%mm0, w
movq%mm0, dw
emms
ret
--
What|Removed |Added
CC||uros at kss-loka dot si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug c/22141] New: Missing optimization when storing structures
In the attached example, the store of type_t is not optimized by gcc. Instead
of storing one 32-bit value, four 8-bit values are stored.
gcc-4.0.1 produces the following code:
/home/fm3/foo.c:16
80483b7: c6 05 13 96 04 08 04movb $0x4,0x8049613
80483be: c6 05 12 96 04 08 03movb $0x3,0x8049612
80483c5: c6 05 11 96 04 08 02movb $0x2,0x8049611
80483cc: c6 05 10 96 04 08 01movb $0x1,0x8049610
gcc-3.4.5 produces the following code:
/home/fm3/foo.c:16
8048391: ba 01 02 03 04 mov$0x4030201,%edx
/home/fm3/foo.c:15
8048396: 89 e5 mov%esp,%ebp
8048398: 83 ec 18sub$0x18,%esp
804839b: 83 e4 f0and$0xfff0,%esp
804839e: 83 ec 10sub$0x10,%esp
/home/fm3/foo.c:16
80483a1: 89 15 1c 96 04 08 mov%edx,0x804961c
(better)
gcc-2.95.4 produces the following code:
/home/fm3/foo.c:16
80483f7: c7 05 84 96 04 08 01movl $0x4030201,0x8049684
80483fe: 02 03 04
(best because no register allocation)
The example:
#include stdio.h
typedef struct
{
unsigned char a;
unsigned char b;
unsigned char c;
unsigned char d;
} type_t;
static type_t u;
int
main(void)
{
u = (type_t){ 1, 2, 3, 4};
printf(%d %d %d %d\n, u.a, u.b, u.c, u.d);
return 0;
}
gcc-4.0 -v -save-temps -g -o foo -W -Wall -Wformat=2 -O3 -Wall -W
-fomit-frame-pointer -march=pentium3 -g foo.c:
Using built-in specs.
Target: i486-linux
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-mpfr --disable-werror --enable-checking=release i486-linux
Thread model: posix
gcc version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9)
/usr/lib/gcc/i486-linux/4.0.1/cc1 -E -quiet -v foo.c -march=pentium3 -W -Wall
-Wformat=2 -Wall -W -fomit-frame-pointer -fworking-directory -O3
-fpch-preprocess -o foo.i
ignoring nonexistent directory
/usr/lib/gcc/i486-linux/4.0.1/../../../../i486-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i486-linux/4.0.1/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux/4.0.1/cc1 -fpreprocessed foo.i -quiet -dumpbase foo.c
-march=pentium3 -auxbase foo -g -g -O3 -W -Wall -Wformat=2 -Wall -W -version
-fomit-frame-pointer -o foo.s
GNU C version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9) (i486-linux)
compiled by GNU C version 4.0.1 20050522 (prerelease) (Debian
4.0.0-9).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64260
as -V -Qy --32 -o foo.o foo.s
GNU assembler version 2.15 (i486-linux-gnu) using BFD version 2.15
/usr/lib/gcc/i486-linux/4.0.1/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o
foo /usr/lib/gcc/i486-linux/4.0.1/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux/4.0.1/../../../../lib/crti.o
/usr/lib/gcc/i486-linux/4.0.1/crtbegin.o
-L/usr/lib/gcc/i486-linux/4.0.1 -L/usr/lib/gcc/i486-linux/4.0.1
-L/usr/lib/gcc/i486-linux/4.0.1/../../../../lib
-L/usr/lib/gcc/i486-linux/4.0.1/../../.. -L/lib/../lib -L/usr/lib/../lib foo.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i486-linux/4.0.1/crtend.o
/usr/lib/gcc/i486-linux/4.0.1/../../../../lib/crtn.o
--
Summary: Missing optimization when storing structures
Product: gcc
Version: 4.0.1
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
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug tree-optimization/22122] [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819
--- Additional Comments From hubicka at ucw dot cz 2005-06-22 11:12 --- Subject: Re: [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819 --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21 12:51 --- Hmm, reconfirmed, then. Strange, the testcase was passing for me when I was testing it on not 100% final version of patch. I will re-check it today. Honza -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22122 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22122
[Bug libfortran/22142] New: eoshift: boundary not filled in correctly
Another corner case of eoshift that's not correct... in eoshift3, this time. $ cat eoshift.f90 program main implicit none integer, dimension (3,3) :: a, b, w integer, dimension (3) :: bo, sh integer :: i,j a = reshape((/(i,i=1,9)/),shape(a)) sh = (/ 3, -1, -3 /) bo = (/-999, -99, -9 /) b = eoshift(a, shift=sh, boundary=bo) w = reshape((/ -999, -999, -999, -99, 4, 5, -9, -9, -9 /), shape(b)) do j=1,3 do i=1,3 if (w(i,j) /= b(i,j)) print *,i,j,w(i,j),b(i,j) end do end do end program main $ gfortran eoshift.f90 $ ./a.out 1 2 -99 -1644167172 1 3 -9-6422529 2 3 -9-6422529 3 3 -9-6422529 $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050618/configure --prefix=/home/zfkts --enable- languages=c,f95 Thread model: posix gcc version 4.1.0 20050618 (experimental) $ nm a.out | grep eoshift U _gfortran_eoshift3_4 -- Summary: eoshift: boundary not filled in correctly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22142
[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 11:41 --- This can be made to fail on any architecture by increasing the amount of shifting: $ cat eoshift-really-fails.f90 program main character(len=20) line write (line,'(I4)') eoshift((/1, 3/), 1000) end program main $ gfortran eoshift-really-fails.f90 $ ./a.out Segmentation fault $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050618/configure --prefix=/home/zfkts --enable- languages=c,f95 Thread model: posix gcc version 4.1.0 20050618 (experimental) The problem is that the code tries to overwrite more than it should for shift len. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21594
[Bug libfortran/22124] eoshift with dim=2 fails
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 11:42 --- This is a duplicate of 21592. The problem is that we are really running off the end here, as Andrew suggested. *** This bug has been marked as a duplicate of 21592 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 11:42 --- *** Bug 22124 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug middle-end/17965] ice in expand_call
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 12:07 --- Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01764.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||06/msg01764.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
[Bug libfortran/22143] New: missing kinds 1 and 2 for eoshift and cshift
$ cat shift-kind.f90 program main implicit none integer, dimension (3,3) :: a, b, w integer(kind=2), dimension (3) :: sh2 integer(kind=1), dimension (3) :: sh1 integer, dimension(3) :: bo integer :: i,j a = reshape((/(i,i=1,9)/),shape(a)) sh1 = (/ -3, -1, 3 /) sh2 = (/ -3, -1, 3 /) bo = (/-999, -99, -9 /) b = cshift(a, shift=sh1) b = cshift(a, shift=sh2) b = eoshift(a, shift=sh1) b = eoshift(a, shift=sh1, boundary=bo) b = eoshift(a, shift=sh2) b = eoshift(a, shift=sh2, boundary=bo) end program main $ gfortran shift-kind.f90 /tmp/cceMvPmd.o(.text+0xa42): In function `MAIN__': : undefined reference to `_gfortran_cshift1_1' /tmp/cceMvPmd.o(.text+0xc82): In function `MAIN__': : undefined reference to `_gfortran_cshift1_2' /tmp/cceMvPmd.o(.text+0xed2): In function `MAIN__': : undefined reference to `_gfortran_eoshift1_1' /tmp/cceMvPmd.o(.text+0x11a2): In function `MAIN__': : undefined reference to `_gfortran_eoshift3_1' /tmp/cceMvPmd.o(.text+0x13f2): In function `MAIN__': : undefined reference to `_gfortran_eoshift1_2' /tmp/cceMvPmd.o(.text+0x16c2): In function `MAIN__': : undefined reference to `_gfortran_eoshift3_2' collect2: ld returned 1 exit status -- Summary: missing kinds 1 and 2 for eoshift and cshift Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143
[Bug libfortran/22144] New: eoshift1, eoshift3, cshift1 lack memory allocation
$ cat cshift-alloc.f90 program main implicit none integer, dimension (:,:),allocatable :: a integer, dimension (3) :: sh integer :: i allocate (a(3,3)) a = reshape((/(i,i=1,9)/),shape(a)) sh = (/ 2, -1, -2 /) write(*,fmt='(10I5)') cshift(a, shift=sh) end program main $ gfortran cshift-alloc.f90 $ ./a.out Segmentation fault $ nm ./a.out | grep shift U _gfortran_cshift1_4 Same thing for eoshift1 and eoshift3. -- Summary: eoshift1, eoshift3, cshift1 lack memory allocation Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22144
[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
13:07 ---
Reduced testcase for the regression:
typedef struct type
{
char a;
char b;
char c;
char d;
} type_t;
type_t u;
void
f(void)
{
u = (type_t){ 1, 2, 3, 4};
}
3.3 produced:
lis r0,0x102
lis r2,ha16(_u)
ori r0,r0,772
stw r0,lo16(_u)(r2)
blr
4.0.0 produces:
lis r11,ha16(_u)
li r0,2
la r9,lo16(_u)(r11)
li r2,1
stb r0,1(r9)
li r0,4
stb r2,lo16(_u)(r11)
li r2,3
stb r0,3(r9)
stb r2,2(r9)
blr
Which is much slower and larger.
Also this is a code size regression even at -Os.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed||1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2005-06-22 13:07:06
date||
Summary|Missing optimization when |[4.0/4.1 Regression] Missing
|storing structures |optimization when storing
||structures
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug target/22145] New: /usr/include/objc/objc-runtime.h on powerpc-darwin7.8.0 needs fixed included
For Obj-C++, /usr/include/objc/objc-runtime.h contains Class class; which will not work with Obj-C++ at all. This causes testsuite failures and causes you not to be able to compile almost any obj-C++ program. -- Summary: /usr/include/objc/objc-runtime.h on powerpc-darwin7.8.0 needs fixed included Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22145
[Bug middle-end/20593] [4.0 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 13:37 --- I committed the patch to the mainline after testing and will commit to the 4.0 branch once reopened so mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|ada |middle-end Summary|[4.0/4.1 Regression] Simple |[4.0 Regression] Simple |array of string access |array of string access |miscompiled on x86 and |miscompiled on x86 and |x86_64 and PPC |x86_64 and PPC Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
[Bug middle-end/20593] [4.0 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 13:38 --- Subject: Bug 20593 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-22 13:38:25 Modified files: gcc: ChangeLog varasm.c Log message: 2005-06-22 Richard Kenner [EMAIL PROTECTED] PR middle-end/20593 * varasm.c (compute_reloc_for_constant): Treat VIEW_CONVER_EXPR the same as the other cast operands. (output_addressed_constants): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9207r2=2.9208 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.513r2=1.514 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
[Bug libfortran/22124] eoshift with dim=2 fails
--- Additional Comments From bangerth at dealii dot org 2005-06-22 14:09 --- Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front end bug. Did you mean that? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124
[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From denis dot nagorny at intel dot com 2005-06-22 14:34 --- Ok. It seems like this issue is mostly fixed now. I incresead NIT counter up to 200 and obtained following results: 3.4.2 ~ 3.4s old 4.0 ~ 6.4s mainline ~ 4.0s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug rtl-optimization/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 14:37 --- I think this is the normal register pressure issue in GCC's RA. See http://www.gccsummit.org/2005/view_abstract.php?content_key=1 for a discussion which will happen later today. -- What|Removed |Added Component|fortran |rtl-optimization Keywords||missed-optimization, ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 15:34 --- Subject: Bug 21034 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-22 15:34:02 Modified files: gcc/fortran: ChangeLog symbol.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: auto_save_1.f90 Log message: 2005-06-22 Paul Brook [EMAIL PROTECTED] PR fortran/21034 * symbol.c (gfc_is_var_automatic): New function. (save_symbol): Use it. testsuite/ * gfortran.dg/auto_save_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.470r2=1.471 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gccr1=1.29r2=1.30 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5670r2=1.5671 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/auto_save_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22 16:00 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug target/21571] ICE in rs6000.c with -msdata=default.
--- Additional Comments From osv at javad dot ru 2005-06-22 16:00 ---
Reproducible on 4.1.0 (mainline) by adding -ffast-math to the command-line:
$ ppc-eabi-gcc -v -msdata=default -ffast-math -c test.cc -o test.o
Using built-in specs.
Target: ppc-eabi
Configured with: ../../gcc/configure --prefix=/home/osv/try/ppc-rtems/tools
--target=ppc-eabi --disable-haifa --disable-newlib-hw-fp --with-gnu-as
--with-gnu-ld -with-newlib --with-cpu=505
Thread model: single
gcc version 4.1.0 20050620 (experimental)
/home/osv/try/ppc-rtems/tools/libexec/gcc/ppc-eabi/4.1.0/cc1plus -quiet -v
test.cc -quiet -dumpbase test.cc -msdata=default -mcpu=505 -auxbase-strip test.o
-version -ffast-math -o /tmp/ccM8Vbir.s
ignoring nonexistent directory
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.1.0/../../../../ppc-eabi/sys-include
#include ... search starts here:
#include ... search starts here:
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.1.0/../../../../include/c++/4.1.0
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.1.0/../../../../include/c++/4.1.0/ppc-eabi
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.1.0/../../../../include/c++/4.1.0/backward
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.1.0/include
/home/osv/try/ppc-rtems/tools/lib/gcc/ppc-eabi/4.1.0/../../../../ppc-eabi/include
End of search list.
GNU C++ version 4.1.0 20050620 (experimental) (ppc-eabi)
compiled by GNU C version 2.95.4 20011002 (Debian prerelease).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 53cb6b81161433cf05f625e722038621
test.cc: In function 'void foo()':
test.cc:2: internal compiler error: in find_addr_reg, at
config/rs6000/rs6000.c:16845
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Compilation exited abnormally with code 1 at Wed Jun 22 19:58:09
In case it helps to debug the problem, here is the insn that causes the ICE:
(insn 9 32 10 (set (mem/i:DF (symbol_ref:SI (zero) [flags 0x6] var_decl
0x401dcf68 zero) [0 zero+0 S8 A64])
(reg:DF 9 %r9 [118])) 350 {*movdf_hardfloat32} (nil)
(nil))
... and here is stack backtrace:
#0 fancy_abort (file=0x89c7b60 ../../../gcc/gcc/config/rs6000/rs6000.c,
line=16845, function=0x89cefcd find_addr_reg)
at ../../../gcc/gcc/diagnostic.c:588
#1 0x08727607 in find_addr_reg (addr=0x40143e60)
at ../../../gcc/gcc/config/rs6000/rs6000.c:16845
#2 0x08541701 in output_350 (operands=0x8a011a0, insn=0x401bf140)
at ../../../gcc/gcc/config/rs6000/rs6000.md:7726
#3 0x08457c69 in get_insn_template (code=350, insn=0x401bf140)
at ../../../gcc/gcc/final.c:1584
#4 0x08458c65 in final_scan_insn (insn=0x401bf140, file=0x8a7cc38,
optimize=0, nopeepholes=0, seen=0xbfffe690)
at ../../../gcc/gcc/final.c:2385
#5 0x08457b85 in final (first=0x401bc200, file=0x8a7cc38, optimize=0)
at ../../../gcc/gcc/final.c:1569
#6 0x086c916c in rest_of_handle_final () at ../../../gcc/gcc/passes.c:293
#7 0x086cbb26 in rest_of_compilation () at ../../../gcc/gcc/passes.c:1747
#8 0x08275f83 in execute_one_pass (pass=0x89ea220)
at ../../../gcc/gcc/tree-optimize.c:629
#9 0x0827608c in execute_pass_list (pass=0x89ea220)
at ../../../gcc/gcc/tree-optimize.c:666
#10 0x08276600 in tree_rest_of_compilation (fndecl=0x401de074)
at ../../../gcc/gcc/tree-optimize.c:829
#11 0x0819a260 in expand_body (fn=0x401de074)
at ../../../gcc/gcc/cp/semantics.c:3018
#12 0x0872f12e in cgraph_expand_function (node=0x401de414)
at ../../../gcc/gcc/cgraphunit.c:968
#13 0x0872f3c4 in cgraph_expand_all_functions ()
at ../../../gcc/gcc/cgraphunit.c:1034
#14 0x0872f9a0 in cgraph_optimize () at ../../../gcc/gcc/cgraphunit.c:1168
#15 0x08119d72 in cp_finish_file () at ../../../gcc/gcc/cp/decl2.c:3104
#16 0x08049d3f in finish_file () at ../../../gcc/gcc/cp/cp-lang.c:113
#17 0x08239dad in c_common_parse_file (set_yydebug=0)
at ../../../gcc/gcc/c-opts.c:1119
#18 0x0867e3e3 in compile_file () at ../../../gcc/gcc/toplev.c:966
#19 0x0867fb58 in do_compile () at ../../../gcc/gcc/toplev.c:1902
#20 0x0867fbc5 in toplev_main (argc=16, argv=0xbfffea14)
at ../../../gcc/gcc/toplev.c:1934
#21 0x08247e96 in main (argc=16, argv=0xbfffea14) at ../../../gcc/gcc/main.c:35
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-22 16:03 --- What about 4.0? Right now, we've been trying to keep all patches applied on both branches. Doesn't this bug happen on 4.0 too? -- What|Removed |Added CC||pbrook at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug target/21571] ICE in rs6000.c with -msdata=default.
-- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug target/21571] ICE in rs6000.c with -msdata=default.
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug tree-optimization/22122] [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819
--- Additional Comments From marcus at jet dot franken dot de 2005-06-22 17:26 --- gcc-Version 4.1.0 20050622 (experimental) ../BIN/bin/gcc -ftree-vectorize -O2 -c ~/thread.i /home/marcus/thread.i: In function 'f': /home/marcus/thread.i:2: internal compiler error: in get_loop_body, at cfgloop.c:819 Please submit a full bug report, -O2 is enough for me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22122
[Bug fortran/22146] New: ICE when calling ELEMENTAL subroutines
$ cat gfortranbug.f90 module buggy contains elemental subroutine foo(a) integer, intent(out) :: a a = 0 end subroutine foo subroutine bar() integer :: a(10) call foo(a) end subroutine bar end module buggy $ gfortran41 -c gfortranbug.f90 gfortranbug.f90: In function 'bar': gfortranbug.f90:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE when calling ELEMENTAL subroutines Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eedelman at acclab dot helsinki dot fi CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22146
[Bug fortran/22146] ICE when calling ELEMENTAL subroutines
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 17:52 --- Confirmed. here is the backtrace: #0 0x080a7931 in gfc_conv_function_call (se=0xbfe81c08, sym=0xa52cf80, arg=0xa52d5b8) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-expr.c:1287 #1 0x080b5842 in gfc_trans_call (code=0xa52d760) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/trans-stmt.c:217 #2 0x08096c88 in gfc_trans_code (code=0xa52d760) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/trans.c:533 #3 0x080a64a8 in gfc_generate_function_code (ns=0xa52d1c8) at /home/peshtigo/pinskia/src/gnu/ gcc/src/gcc/fortran/trans-decl.c:2358 #4 0x08096fb2 in gfc_generate_module_code (ns=0xa52c858) at /home/peshtigo/pinskia/src/gnu/ gcc/src/gcc/fortran/trans.c:706 #5 0x0807cc76 in gfc_parse_file () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/parse.c: 2629 #6 0x08094085 in gfc_be_parse_file (set_yydebug=0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/f95-lang.c:263 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-22 17:52:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22146
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 17:59 --- I am running into this as well. Turning off all optimizations (-O0) allows compilation, anything over -O1 hits it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug c++/22147] New: [4.1 regression] ICE in get_bindings
The following code ICEs:
// Line 1
class A {
public:
A() { };
~A() { };
};
class B {
public:
B();
B(const A a) { };
~B();
};
template typename X class T;
template typename X, typename Y
TX* func(TY* p);
template typename X class T {
X*m_;
public:
T(X* x) : m_(x) { };
~T() { };
friend Tclass Y* funcY, X(TX* p);
};
template typename X, typename Y
TX* func(TY* p) {
return (new TX(new X(*p-m_)));
}
int main() {
A* a = new A();
TA*p = new TA(a);
TB*q = funcB, A(p);
return 0;
}
--
Summary: [4.1 regression] ICE in get_bindings
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug c++/22147] [4.1 regression] ICE in get_bindings
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug target/22148] New: gcc.dg/vect/vect-reduc-1* fail
The following FAILs have appeared on ia64-hpux (both -milp32 and -mlp64) on mainline on 20050622. gcc-testresults shows them also on ia64-linux. FAIL: gcc.dg/vect/vect-reduc-1char.c (test for excess errors) FAIL: gcc.dg/vect/vect-reduc-1.c (test for excess errors) The first is a new test. The second test has changed in the relevant period. vect-reduc-1.c failure: /home/gcc/nightlies/src-mainline-2005-06-22/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-1.c: In function 'main1': /home/gcc/nightlies/src-mainline-2005-06-22/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-1.c:44: error: unrecognizable insn: (insn 122 121 123 4 (set (reg:SI 447) (if_then_else:SI (reg:BI 445) (subreg:SI (reg:V2SI 406 [ vect_var_.62 ]) 4) (subreg:SI (reg:V2SI 440) 4))) -1 (nil) (nil)) /home/gcc/nightlies/src-mainline-2005-06-22/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-1.c:44: internal compiler error: in extract_insn, at recog.c:2082 vect-reduc-1char.c failure: /home/gcc/nightlies/src-mainline-2005-06-22/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-1char.c: In function 'main1': /home/gcc/nightlies/src-mainline-2005-06-22/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-1char.c:39: error: unrecognizable insn: (insn 120 119 121 1 (set (reg:V8QI 384 [ vect_var_.80 ]) (smax:V8QI (reg:V8QI 384 [ vect_var_.80 ]) (reg:V8QI 473))) -1 (nil) (nil)) /home/gcc/nightlies/src-mainline-2005-06-22/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-reduc-1char.c:39: internal compiler error: in extract_insn, at recog.c:2082 -- Summary: gcc.dg/vect/vect-reduc-1* fail Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22148
[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:17 --- I'd like to move this to gcc-4_0-branch. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug target/22148] gcc.dg/vect/vect-reduc-1* fail
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22148
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22 18:51 --- Reopening until 4.0 is unforzen and the patch applied there -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2005-04-15 08:30:11 |2005-06-22 18:51:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] [4.0 only] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
-- What|Removed |Added Keywords||ice-on-valid-code Summary|internal compiler error: in |[4.0 only] internal compiler |gfc_trans_auto_array_allocat|error: in |ion, at fortran/trans- |gfc_trans_auto_array_allocat |array.c:3036|ion, at fortran/trans- ||array.c:3036 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22 18:54 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Wed, 2005-06-22 at 17:59 +, bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 17:59 --- I am running into this as well. Turning off all optimizations (-O0) allows compilation, anything over -O1 hits it. This one is because of structures with a lot of holes in them, where we make accesses that bridge the hole, and cna't ind the field that gets associated with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59 --- Ah, the old can't find the tunnel at the end of the bridge at the end of this hole problem. Bummer. I hate it when that happens. Is there an easier way than -O0 to revert back to the old behavior? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug c++/22149] New: func pointer non-type template parm invalid access control
I notice that program1 (the 1st program attached below) fails to compile, but
very similar programs 2 and 3 (attached further below) do. The only difference
being related to how the non-type template parameter is declared void (*FOOBAR)
() vs void FOOBAR () vs void (FOOBAR) ().
/cygdrive/d/users/hill/tmp/daTest$ g++ cat.cpp
cat.cpp: In constructor `fooFOOBAR::foo() [with void (*FOOBAR)() = bar::foobar
]':
cat.cpp:12: instantiated from here
cat.cpp:15: error: `static void bar::foobar()' is private
cat.cpp:7: error: within this context
-program1--snip--snip-
template void (*FOOBAR) ()
class foo {
public:
foo () { (*FOOBAR) (); }
};
class bar {
public:
bar () { foo bar::foobar tmp; }
private:
static void foobar ()
{
}
};
main ()
{
bar b;
}
-program2--snip--snip-
template void FOOBAR ()
class foo {
public:
foo () { FOOBAR (); }
};
class bar {
public:
bar () { foo bar::foobar tmp; }
private:
static void foobar ()
{
}
};
main ()
{
bar b;
}
program3---snip--snip-
template void ( FOOBAR) ()
class foo {
public:
foo () { FOOBAR (); }
};
class bar {
public:
bar () { foo bar::foobar tmp; }
private:
static void foobar ()
{
}
};
main ()
{
bar b;
}
---snip--snip-
/cygdrive/d/users/hill/tmp/daTest$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --
exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --man
dir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,
java,objc --enable-nls --without-included-gettext --enable-version-specific-runt
ime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --ena
ble-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=b
oehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchroniza
tion --enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
--
Summary: func pointer non-type template parm invalid access
control
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: johill at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22149
[Bug SWING/22150] New: BasicTreeUI Implementation
Implementation not complete -- Summary: BasicTreeUI Implementation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: langel at redhat dot com ReportedBy: langel at redhat dot com 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=22150
Re: [Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59 --- Ah, the old can't find the tunnel at the end of the bridge at the end of this hole problem. Bummer. I hate it when that happens. Is there an easier way than -O0 to revert back to the old behavior? yes -fno-tree-salias. -- Pinski
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-22 19:02 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59 --- Ah, the old can't find the tunnel at the end of the bridge at the end of this hole problem. Bummer. I hate it when that happens. Is there an easier way than -O0 to revert back to the old behavior? yes -fno-tree-salias. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug SWING/22150] BasicTreeUI Implementation
--- Additional Comments From langel at redhat dot com 2005-06-22 19:06 --- I am working on this! -- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22150
[Bug SWING/22151] New: JInternalFrame causes OutOfMemory error when maximized.
JInternalFrame causes OutOfMemory error when maximized.
Run the test case below, maximize the JInternalFrame, wait a while. OutOfMemory
error.
When the JInternalFrame is positioned at (10,10) rather than (60,60) the error
doesn't occur.
==TEST CASE==
import java.awt.*;
import javax.swing.*;
import java.io.*;
public class OutOfMemory {
public static void main(String[] a) throws IOException{
JFrame myFrame = new JFrame(Outer);
myFrame.setSize(300,300);
myFrame.setContentPane(new JDesktopPane());
JInternalFrame f = new JInternalFrame(Internal);
f.setSize(200,200);
f.setVisible(true);
f.setClosable(true);
f.setMaximizable(true);
f.setResizable(true);
f.setIconifiable(true);
/* IF THE FOLLOWING LINE IS CHANGED TO f.setLocation (10,10)
no OutOfMemory error occurs! */
f.setLocation(60,50);
myFrame.add(f);
myFrame.setVisible(true);
}
}
--
Summary: JInternalFrame causes OutOfMemory error when maximized.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: SWING
AssignedTo: abalkiss at redhat dot com
ReportedBy: abalkiss at redhat dot com
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=22151
[Bug c++/22149] func pointer non-type template parm invalid access control
-- What|Removed |Added Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 ||3.4.0 4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22149
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22 19:23 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Wed, 2005-06-22 at 19:02 +, pinskia at physics dot uc dot edu wrote: --- Additional Comments From pinskia at physics dot uc dot edu 2005-06-22 19:02 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59 --- Ah, the old can't find the tunnel at the end of the bridge at the end of this hole problem. Bummer. I hate it when that happens. Is there an easier way than -O0 to revert back to the old behavior? yes -fno-tree-salias. No, that won't help either :) There is no way to revert to the old behavior, you'd have to add flags for PTA, which will break the SSA path, since we rely on it) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check
--- Additional Comments From mark at codesourcery dot com 2005-06-22 19:46 --- Subject: Re: [4.0 Regression] libstdc++ abi_check bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:17 --- I'd like to move this to gcc-4_0-branch. Please go ahead. Thanks for doing this in a way that will work with installed-tree testing! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug rtl-optimization/22152] New: Poor loop optimization when using sse2 builtins - regression from 3.3
In the following trivial test case, gcc-4.1 produces very ineffecient code for
the loop. gcc-3.3 produces
much better code.
typedef int __m64 __attribute__ ((__vector_size__ (8)));
__m64 unsigned_add3( const __m64 *a, const __m64 *b, unsigned long count )
{
__m64 sum;
unsigned int i;
for( i = 1; i count; i++ )
{
sum = (__m64) __builtin_ia32_paddq ((long long)a[i],
(long long)b[i]);
}
return sum;
}
1) Loop when compiled with gcc-4.1 -O2 -msse2 (note in particular the extra
movq to memory):
L4:
movl12(%ebp), %esi
movq(%eax,%edx,8), %mm0
paddq (%esi,%edx,8), %mm0
incl%edx
cmpl%edx, %ecx
movq%mm0, -16(%ebp)
movl-16(%ebp), %esi
movl-12(%ebp), %edi
jne L4
2) Loop using gcc-3.3 compiled with -O2 -msse2:
L6:
movq(%esi,%edx,8), %mm0
paddq (%eax,%edx,8), %mm0
addl$1, %edx
cmpl%ecx, %edx
jb L6
AFAICT, culprit is reload which generates extra load and store of %mm0:
(insn 62 30 63 2 (set (mem:V2SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 S8 A8])
(reg:V2SI 29 mm0)) 736 {*movv2si_internal} (nil)
(nil))
(insn 63 62 32 2 (set (reg/v:V2SI 4 si [orig:61 sum ] [61])
(mem:V2SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 S8 A8])) 736
{*movv2si_internal} (nil)
(nil))
Here is the larger test case from which above test was extracted:
#include xmmintrin.h
__m64 unsigned_add3( const __m64 *a, const __m64 *b, __m64 *result, unsigned
long count )
{
__m64 carry, temp, sum, one, onesCarry, _a, _b;
unsigned int i;
if( count 0 )
{
_a = a[0];
_b = b[0];
one = _mm_cmpeq_pi8( _a, _a ); //-1
one = _mm_sub_si64( _mm_xor_si64( one, one ), one );//1
sum = _mm_add_si64( _a, _b );
onesCarry = _mm_and_si64( _a, _b ); //the 1's bit
is set only if the 1's bit add
generates a carry
onesCarry = _mm_and_si64( onesCarry, one );
//onesCarry = 1
//Trim off the one's bit on both vA and vB to make room for a
carry bit at the top after the
add
_a = _mm_srli_si64( _a, 1 );
//vA = 1
_b = _mm_srli_si64( _b, 1 );
//vB = 1
//Add vA to vB and add the carry bit
carry = _mm_add_si64( _a, _b );
carry = _mm_add_si64( carry, onesCarry );
//right shift by 63 bits to get the carry bit for the high 64
bit quantity
carry = _mm_srli_si64( carry, 63 );
for( i = 1; i count; i++ )
{
result[i-1] = sum;
_a = a[i];
_b = b[i];
onesCarry = _mm_and_si64( _a, _b );
onesCarry = _mm_and_si64( onesCarry, one );
sum = _mm_add_si64( _a, _b );
_a = _mm_add_si64( _a, onesCarry );
onesCarry = _mm_and_si64( carry, _a ); //find low bit
carry
sum = _mm_add_si64( sum, carry ); //add
in carry bit to low word sum
carry = _mm_add_si64( _a, onesCarry ); //add in low
bit carry to high result
}
result[i-1] = sum;
}
return carry;
}
Again, gcc-3.3 produces much better code for this loop.
--
Summary: Poor loop optimization when using sse2 builtins -
regression from 3.3
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: apple-x86-darwin
GCC host triplet: apple-x86-darwin
GCC target triplet: apple-x86-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 20:13 --- Can somebody do a binary search and find out what patch or patches broke this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug rtl-optimization/22152] Poor loop optimization when using mmx builtins
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:16 --- This is a MMX builtin and not a SSE builtin. -- What|Removed |Added GCC build triplet|apple-x86-darwin| GCC host triplet|apple-x86-darwin| GCC target triplet|apple-x86-darwin|i?86-*-*, x86_64-*-* Keywords||missed-optimization Summary|Poor loop optimization when |Poor loop optimization when |using sse2 builtins - |using mmx builtins |regression from 3.3 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug libfortran/22124] eoshift with dim=2 fails
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 20:18 --- (In reply to comment #3) Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front end bug. Did you mean that? No, I meant 21594. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124
[Bug target/22152] Poor loop optimization when using mmx builtins
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:26 --- This comes down to PR 14552 and PR 19161. Since this is MMX code, it is very hard to get correct as GCC does not currently output emms and vector code without you doing it which is what PR 19161 is about. This is a target problem. Also see PR 22076. -- What|Removed |Added BugsThisDependsOn||14552, 19161, 22076 Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-22 20:26:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
[Bug target/22076] Strange code for MMX register moves
-- What|Removed |Added OtherBugsDependingO||22152 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
[Bug target/22076] Strange code for MMX register moves
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:27 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-06-22 20:27:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:29 --- (In reply to comment #11) Can somebody do a binary search and find out what patch or patches broke this? No need to as it is obvious what caused it as the person who caused it already commented on this, it was introduced when tree-ssa-structalias.c was added. 2005-06-08 Daniel Berlin [EMAIL PROTECTED] * Makefile.in (OBJS-common): Add tree-ssa-structalias.o. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 20:47 --- Subject: Bug 22111 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-22 20:39:41 Modified files: libstdc++-v3 : ChangeLog Makefile.in acinclude.m4 configure libstdc++-v3/include: Makefile.in libstdc++-v3/libmath: Makefile.in libstdc++-v3/libsupc++: Makefile.in libstdc++-v3/po: Makefile.in libstdc++-v3/src: Makefile.in libstdc++-v3/testsuite: Makefile.am Makefile.in libstdc++-v3/testsuite/lib: libstdc++.exp libstdc++-v3/testsuite/libstdc++-abi: abi.exp Log message: 2005-06-22 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/22111 * acinclude.m4 (GLIBCXX_CONFIGURE_TESTSUITE): Remove GLIBCXX_TEST_ABI. Remove duplicate _GLIBCXX_ASM_SYMVER define. Don't enable abi testing unless versioned. * configure: Regenerate. * testsuite/Makefile.am (check-abi): Remove conditional. * testsuite/Makefile.in: Regenerate. * testsuite/libstdc++-abi/abi.exp: Call build_support, then check v3-symver before proceeding. * testsuite/lib/libstdc++.exp (libstdc++-dg-test): Set v3-symvers if _GLIBCXX_SYMVER. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.62r2=1.2917.2.63 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.155.6.1r2=1.155.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.307.2.2r2=1.307.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.423.2.3r2=1.423.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.126.2.4r2=1.126.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/libmath/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.106r2=1.106.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/libsupc++/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.121r2=1.121.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/po/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.51r2=1.51.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.217.6.1r2=1.217.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/Makefile.am.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.42.6.2r2=1.42.6.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.88.6.3r2=1.88.6.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/lib/libstdc++.exp.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32.4.3r2=1.32.4.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3.8.1r2=1.3.8.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 20:49 --- Subject: Bug 17383 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-22 20:42:06 Modified files: . : ChangeLog configure.in configure Log message: 2005-06-22 Eric Christopher [EMAIL PROTECTED] PR bootstrap/17383 * configure.in: Reject building in the source directory. * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1057.2.15r2=1.1057.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.341.2.4r2=1.341.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.204.2.5r2=1.204.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17383
[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22 20:50 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Wed, 2005-06-22 at 20:13 +, bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 20:13 --- Can somebody do a binary search and find out what patch or patches broke this? I know what broke it. It was the structalias commit i did when it was added to the mainline. I'll fix it in the next few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-22 20:53 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug AWT/19840] drawImage bug
--- Additional Comments From mark at gcc dot gnu dot org 2005-06-22 21:29 --- This seems to have been fixed in GNU Classpath by Sven de Marothy. http://fitzsim.org/blog/?p=5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug c++/22147] [4.1 regression] ICE in get_bindings
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-22
21:41 ---
Confirmed. Reduced testcase:
templatetypename struct A;
templatetypename T void foo(AT* p) { *p; }
templatetypename struct A
{
friend void fooclass X(AX*);
};
void bar()
{
fooint(0);
}
Crashes mainline since at least 2005-05-25.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2005-06-22 21:41:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug c++/22153] New: [3.4/4.0/4.1 regression] ICE on invalid template specialization
Since GCC 3.4.0 we get an ICE on the following invalid code snippet:
===
templateint void foo();
templateint struct A
{
template friend void foo0();
};
===
bug.cc:5: error: invalid explicit specialization before '' token
bug.cc:5: error: explicit specialization in non-namespace scope 'struct
Aanonymous '
bug.cc:5: error: enclosing class templates are not explicitly specialized
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [3.4/4.0/4.1 regression] ICE on invalid template
specialization
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 21:59 --- Yup, excited, today, I just compiled the mainbranch to check this out (gcc-4.1-20050618) and it seems to be fixed! I don't see any strange movlps in any of the code I tried to compile with it. Can be moved to FIXED (I'm not sure I should be to one to switch it??) -- What|Removed |Added Status|SUSPENDED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 22:10 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-06-22 22:10:35 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 22:17 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-22 22:34 --- Fixed in gcc 4.0.1 and mainline by the new .po file. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 22:59 --- Thanks to Uros and everybody! -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug c/20631] Support -std=c90 as alias for -std=c89
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 00:21 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-23 00:21:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20631
[Bug c++/16635] g++ instantiates templates at the wrong place
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 01:19 --- (In reply to comment #5) Here's the same thing with overloaded functions, causing a wrong-code error. If the last definition of 'bar' is commented out, the testcase passes, but otherwise not. That code is acutally invalid and really should have been rejected see PR 2922 for that. -- What|Removed |Added Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16635
[Bug c++/16635] g++ instantiates templates at the wrong place
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 01:27 --- (In reply to comment #6) (In reply to comment #5) Here's the same thing with overloaded functions, causing a wrong-code error. If the last definition of 'bar' is commented out, the testcase passes, but otherwise not. That code is acutally invalid and really should have been rejected see PR 2922 for that. Also if we move the template func after bar and main after the second bar, we get back to basicially PR 2922. So the first testcase is the only one which the problem for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16635
[Bug c++/22147] [4.1 regression] ICE in get_bindings
--- Additional Comments From bangerth at dealii dot org 2005-06-23 02:45 --- Is this really valid? class Y is undeclared at the point of the friend declaration... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug c++/6273] [4.0/4.1 regression] User-defined operator+ and use of enum values in computation of array bounds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
03:47 ---
(In reply to comment #7)
-
template typename struct X {
enum { N = 10 };
int items[N+1];
};
template typename A, typename B int operator+(A,B);
Xint x;
--
Actually I think there is two different bugs here, the above code is vaild I
think because operators just
like functions have an overloaded set for lookup which is PR 2922.
The testcase which is questionable is:
template typename A, typename B int operator+(A,B);
template typename struct X {
enum a{ N = 10 };
int items[N+1];
};
Xint x;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
[Bug c++/22154] New: [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
The following should compile according to this DR report (but it is only in
ready state so I am going to
confirm it and then suspend it):
class a {};
typename ::a f();
Also the following should not compile as a is not qualified then:
class a {};
typename a f();
--
Summary: [DR 382] qualified names should allow typename keyword
in front of it (even in non-templates)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 04:27 --- Confirmed, to ... -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||2.95.3 3.3.5 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-06-23 04:27:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 04:28 --- Suspend this as it only in the ready state. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
[Bug libmudflap/22155] New: ICE with: -fmudflap -D_GLIBCXX_DEBUG
I get an ICE for gcc 4.0.0 when trying to use mudflap and libstdc++ debug mode
together; This is the smallest testcase I could make:
test.cc:
#include vector
struct S { unsigned i; };
void g(const unsigned u, std::vectorunsigned s);
void f(const S s) {
std::vectorstd::vectorunsigned t(1);
g(s.i,t[0]);
}
$ g++ -D_GLIBCXX_DEBUG -fmudflap -c test.cc
test.cc: In function 'void f(const S)':
test.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --enable-languages=c,c++
--prefix=/home/ctsa/opt/i686-linux/gcc-4.0.0 --enable-concept-checks
--enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0
--
Summary: ICE with: -fmudflap -D_GLIBCXX_DEBUG
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ctsa at u dot washington dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22155
[Bug libmudflap/22155] ICE with: -fmudflap -D_GLIBCXX_DEBUG
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 04:43 --- I thought there was a bug about something like this before (and it was fixed too) but I cannot find it right now, maybe I am not looking hard enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22155
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
-- What|Removed |Added BugsThisDependsOn||22156 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
[Bug middle-end/22156] New: [4.0/4.1 Regression] bit-field copying regressed
Take the following code:
struct s
{
int i1:1;
int i2:1;
int i3:1;
};
void f(struct s *x, struct s *y) { *x = *y; }
In 3.4.0 (and currently with the C++ compiler too), we were able to get optimal
code:
movl8(%esp), %eax
movl(%eax), %edx
movl4(%esp), %eax
movl%edx, (%eax)
ret
But in (and after) 4.0.0 and the C compiler we get:
f:
pushl %esi
pushl %ebx
movl16(%esp), %eax
movl12(%esp), %esi
movzbl (%eax), %eax
movb%al, %dl
movb%al, %bl
salb$5, %al
sarb$7, %al
movzbl %al, %ecx
movl(%esi), %eax
salb$6, %dl
andl$1, %ecx
sarb$7, %dl
movzbl %dl, %edx
salb$7, %bl
andl$-7, %eax
sall$2, %ecx
andl$1, %edx
sarb$7, %bl
addl%edx, %edx
orl %ecx, %eax
orl %edx, %eax
movzbl %bl, %edx
andl$1, %edx
andl$-2, %eax
orl %edx, %eax
movl%eax, (%esi)
popl%ebx
popl%esi
ret
Which is much worse
--
Summary: [4.0/4.1 Regression] bit-field copying regressed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19466
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 05:04 --- Note this also effects PPC, though not as badly as there is only one load: in 3.3.3: _f: lwz r0,0(r4) stw r0,0(r3) blr in 4.0.0 and above: _f: lwz r11,0(r4) lwz r0,0(r3) slwi r2,r11,2 slwi r9,r11,1 rlwimi r0,r2,30,2,2 rlwimi r0,r9,31,1,1 rlwimi r0,r11,0,0,0 stw r0,0(r3) blr -- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 05:05 --- Oh and I thought I saw a bug or two about this before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 05:11 --- The main difference between the C++ front-end and the C front-end in this respect is how they repesent bit-fields. for the C++ front-end we get the following output from SRA: Cannot scalarize variable D.1693 because its type cannot be decomposed but for the C front-end we get: Scan results: D.1237: n_uses=0 n_copies=2 Initial instantiation for D.1237 Using element-copy for D.1237 D.1237.i1 - SR.12 D.1237.i2 - SR.13 D.1237.i3 - SR.14 So to me this looks like a SRA bug in that it should be using BIT_FIELD_REF instead if it can. -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug tree-optimization/22157] New: [4.0/4.1 Regression] struct copying code gen
Take the following code:
struct s
{
short t;
short y1;
};
void f(struct s *x, struct s *y)
{
struct s t = *x;
*y = t;
}
In 3.4.0, we produced:
_f:
lwz r0,0(r3)
stw r0,0(r4)
blr
but in 4.0.0 and above:
_f:
lhz r2,2(r3)
lha r0,0(r3)
sth r2,2(r4)
sth r0,0(r4)
blr
I am starting to think we should use VIEW_CONVERT_EXPR in SRA and store it into
a type which is the
same as the mode if the mode is not BKL_MODE (RTL mode by the way) and we don't
access the
temporary variable's fields. That would fix PR 22156 also. Maybe I can look
into doing this.
--
Summary: [4.0/4.1 Regression] struct copying code gen
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot
org
OtherBugsDependingO 22156
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22157
[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed
-- What|Removed |Added BugsThisDependsOn||22157 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug tree-optimization/22157] [4.0/4.1 Regression] struct copying code gen
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22157
