[Bug c/40454] New: GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
Hi, I notice that PNGCrush compiled with GCC 4.4.0 (release) is about 20% slower compared to GCC 3.4.0 build. (Amiga 68...@50mhz). CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s PNGCrush test.png out.png Here are the results: GCC 3.4.0 build: CPU time used = 267.340 seconds (decoding 16.940, encoding 247.800, other 2.600 seconds) GCC 4.4.0 build: CPU time used = 328.360 seconds (decoding 16.800, encoding 309.260, other 2.300 seconds) Maybe someone with m68k Debian/PPC/x86 can compile PNGCrush with GCC 3.4.0 and GCC 4.4.0, so we will know if this regression happens there too? Here is a link to the source code (I used PNGCrush 1.6.15 for test): http://sourceforge.net/project/showfiles.php?group_id=1689&package_id=1641 Here is a link to PNG image: http://www.filejumbo.com/Download/D8F7981723E5F07C/ Regards -- Summary: GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ami_stuff at o2 dot pl GCC host triplet: i686-cygwin GCC target triplet: m68k-amigaos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #1 from ami_stuff at o2 dot pl 2009-06-18 11:27 --- Anyone can try to reproduce this bug on his system? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug inline-asm/40819] New: 32x32->64 - asm code from "longlong.h" is not inlined for 68060's builds
Hi,
There is an asm code for 32x32->64 function in the "longlong.h" file which can
be used for 68060 CPU:
#define umul_ppmm(xh, xl, a, b) \
__asm__ ("| Inlined umul_ppmm\n" \
"move%.l %2,%/d0\n" \
"move%.l %3,%/d1\n" \
"move%.l %/d0,%/d2\n"\
"swap%/d0\n" \
"move%.l %/d1,%/d3\n"\
"swap%/d1\n" \
"move%.w %/d2,%/d4\n"\
"mulu%/d3,%/d4\n"\
"mulu%/d1,%/d2\n"\
"mulu%/d0,%/d3\n"\
"mulu%/d0,%/d1\n"\
"move%.l %/d4,%/d0\n"\
"eor%.w %/d0,%/d0\n"\
"swap%/d0\n" \
"add%.l %/d0,%/d2\n"\
"add%.l %/d3,%/d2\n"\
"jcc 1f\n" \
"add%.l %#65536,%/d1\n" \
"1: swap%/d2\n" \
"moveq %#0,%/d0\n" \
"move%.w %/d2,%/d0\n"\
"move%.w %/d4,%/d2\n"\
"move%.l %/d2,%1\n" \
"add%.l %/d1,%/d0\n"\
"move%.l %/d0,%0"\
: "=g" ((USItype) (xh)), \
"=g" ((USItype) (xl)) \
: "g" ((USItype) (a)), \
"g" ((USItype) (b))\
: "d0", "d1", "d2", "d3", "d4")
but it looks like in some cases(?) this asm inline is not used, so as a result
binaries generated for 68060 CPU (which heavy use 32x32->64 functions) are
about 40% slower (FFmpeg's MP3 decoder).
Here is generic C code:
#include
inline int MULH(int a, int b){
return ((int64_t)(a) * (int64_t)(b))>>32;
}
Here is asm output from GCC 4.4.0 (-m68060 -O3 -fomit-frame-pointer):
#NO_APP
.text
.even
.globl _MULH
_MULH:
move.l d3,-(sp)
move.l d2,-(sp)
move.l 12(sp),d1
smi d0
extb.l d0
move.l 16(sp),d3
smi d2
extb.l d2
move.l d2,a0
move.l d3,a1
move.l a1,-(sp)
move.l a0,-(sp)
move.l d1,-(sp)
move.l d0,-(sp)
jsr ___muldi3
lea (16,sp),sp
move.l d0,d1
smi d0
extb.l d0
move.l d1,d0
move.l (sp)+,d2
move.l (sp)+,d3
rts
The same problem happens for functions defined like this:
#define MULL(a,b,s) (((int64_t)(a) * (int64_t)(b)) >> (s))
#define MUL64(a,b) ((int64_t)(a) * (int64_t)(b))
#define MAC64(d, a, b) ((d) += MUL64(a, b))
#define MLS64(d, a, b) ((d) -= MUL64(a, b))
Regards
--
Summary: 32x32->64 - asm code from "longlong.h" is not inlined
for 68060's builds
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ami_stuff at o2 dot pl
GCC host triplet: i686-cygwin
GCC target triplet: m68k-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40819
[Bug c/40977] New: Problem with code like this: res = ((uint64_t)resh << 32) | resl;
d0,d3
mulud0,d1
movel d4,d0
eorwd0,d0
swapd0
addld0,d2
addld3,d2
jcc 1f
addl#65536,d1
1: swapd2
moveq #0,d0
movew d2,d0
movew d4,d2
movel d2,d6
addld1,d0
movel d0,d5
#NO_APP
tstl a1
jlt L5
tstl a0
jge L3
jra L6
.even
L5:
subl a0,d5
tstl a0
jge L3
.even
L6:
subl a1,d5
.even
L3:
movel d5,d0
clrl d1
orl d6,d1
moveml s...@+,#0x7c
rts
For GCC 4.4.1 the best asm code is generaded from this C code:
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
#define umul_ppmm(xh, xl, a, b) \
__asm__ ("| Inlined umul_ppmm\n" \
"move%.l %2,%/d5\n" \
"move%.l %3,%/d6\n" \
"move%.l %/d5,%/d2\n"\
"swap%/d5\n" \
"move%.l %/d6,%/d3\n"\
"swap%/d6\n" \
"move%.w %/d2,%/d4\n"\
"mulu%/d3,%/d4\n"\
"mulu%/d6,%/d2\n"\
"mulu%/d5,%/d3\n"\
"mulu%/d5,%/d6\n"\
"move%.l %/d4,%/d5\n"\
"eor%.w %/d5,%/d5\n"\
"swap%/d5\n" \
"add%.l %/d5,%/d2\n"\
"add%.l %/d3,%/d2\n"\
"jcc 1f\n" \
"add%.l %#65536,%/d6\n" \
"1: swap%/d2\n" \
"moveq %#0,%/d5\n" \
"move%.w %/d2,%/d5\n"\
"move%.w %/d4,%/d2\n"\
"move%.l %/d2,%1\n" \
"add%.l %/d6,%/d5\n"\
"move%.l %/d5,%0"\
: "=g" ((uint32_t) (xh)),\
"=g" ((uint32_t) (xl)) \
: "g" ((uint32_t) (a)), \
"g" ((uint32_t) (b)) \
: "d2", "d3", "d4", "d5", "d6")
inline uint64_t MUL64(int a, int b)
{
uint32_t au = a;
uint32_t bu = b;
union
{
struct
{
uint32_t h, l;
} parts;
uint64_t whole;
} res;
umul_ppmm(res.parts.h, res.parts.l, au, bu);
if (a < 0)
res.parts.h -= bu;
if (b < 0)
res.parts.h -= au;
return res.whole;
}
Asm output:
#NO_APP
.text
.even
.globl _MUL64
_xxMULH:
movem.l #15872,-(sp)
move.l 24(sp),a0
move.l 28(sp),a1
#APP
| Inlined umul_ppmm
move.l a0,d5
move.l a1,d6
move.l d5,d2
swapd5
move.l d6,d3
swapd6
move.w d2,d4
mulud3,d4
mulud6,d2
mulud5,d3
mulud5,d6
move.l d4,d5
eor.w d5,d5
swapd5
add.l d5,d2
add.l d3,d2
jcc 1f
add.l #65536,d6
1: swapd2
moveq #0,d5
move.w d2,d5
move.w d4,d2
move.l d2,d1
add.l d6,d5
move.l d5,d0
#NO_APP
tst.l a0
jlt L6
tst.l a1
jlt L7
L3:
movem.l (sp)+,#124
rts
L7:
sub.l a0,d0
movem.l (sp)+,#124
rts
L6:
sub.l a1,d0
tst.l a1
jge L3
Maybe someone will teach GCC 4.4.x to use optimized code with:
res = ((uint64_t)resh << 32) | resl;
?
Regards
--
Summary: Problem with code like this: res = ((uint64_t)resh <<
32) | resl;
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ami_stuff at o2 dot pl
GCC host triplet: i686-cygwin
GCC target triplet: m68k-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #2 from ami_stuff at o2 dot pl 2009-08-12 12:09 --- The same problem happens with GCC 4.4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #3 from ami_stuff at o2 dot pl 2009-08-16 01:28 --- This slowdown is because of libz. When I use minigzip from libz package to compress data, I get the same slowdown with GCC 4.4.1. Maybe someone will try to fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #4 from ami_stuff at o2 dot pl 2009-08-16 14:02 --- The problematic source code is deflate.c from libz. CFLAGS=-O3 -DUSE_MMAP -m68060 -fomit-frame-pointer When I compile all source code with GCC 4.4.1, I get slow minigzip binary. When I compile all source code with GCC 4.4.1 except deflate.c (this one I compile with GCC 3.4.0), I get minigzip binary with normal speed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #6 from ami_stuff at o2 dot pl 2009-08-17 09:21 --- Created an attachment (id=18377) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18377&action=view) preprocessed file from GCC 3.4.0 (compiles with GCC 4.4.1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #7 from ami_stuff at o2 dot pl 2009-08-17 09:21 --- Created an attachment (id=18378) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18378&action=view) preprocessed file from GCC 4.4.1 (compiles with GCC 3.4.0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #8 from ami_stuff at o2 dot pl 2009-08-17 09:22 --- Created an attachment (id=18379) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18379&action=view) Assembler output from GCC 3.4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #9 from ami_stuff at o2 dot pl 2009-08-17 09:23 --- Created an attachment (id=18380) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18380&action=view) assembler output from GCC 4.4.1 -- ami_stuff at o2 dot pl changed: What|Removed |Added Attachment #18379|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #10 from ami_stuff at o2 dot pl 2009-08-17 09:23 --- Created an attachment (id=18381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18381&action=view) assembler output from GCC 3.4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #11 from ami_stuff at o2 dot pl 2009-08-17 09:26 --- Preprocessed files compiles with GCC 3.4.0 and GCC 4.4.1. I added them as an attachments plus asm output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - at -O3, PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #13 from ami_stuff at o2 dot pl 2009-08-17 15:17 --- Here are the results from 68...@50mhz: minigzip_340_O1 testa.tif - 34s minigzip_340_O2 testa.tif - 31s minigzip_340_O3 testa.tif - 31s minigzip_441_O1 testa.tif - 40s minigzip_441_O2 testa.tif - 38s minigzip_441_O3 testa.tif - 42s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #7 from ami_stuff at o2 dot pl 2009-08-17 19:25 --- The problem is not with "-funswitch-loops" optimization. I get no ICE with these options (-O2 -fipa-cp-clone -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning): OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O2 -fipa-cp-clone -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning I get ICE with -O3: OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O3 Also, ICE happens ONLY with -m68060 flag! When I use "-m68020 -m6881" or -m68040 there is no ICE! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #8 from ami_stuff at o2 dot pl 2009-08-17 19:33 --- (In reply to comment #7) > The problem is not with "-funswitch-loops" optimization. > > I get no ICE with these options (-O2 -fipa-cp-clone -finline-functions > -fgcse-after-reload -ftree-vectorize -fpredictive-commoning): > > OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement > -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE > -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -fno-common > -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls > -Wcast-qual -Wwrite-strings -Wundef -O2 -fipa-cp-clone -finline-functions > -fgcse-after-reload -ftree-vectorize -fpredictive-commoning > > I get ICE with -O3: > > OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement > -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE > -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -fno-common > -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls > -Wcast-qual -Wwrite-strings -Wundef -O3 > > Also, ICE happens ONLY with -m68060 flag! When I use "-m68020 -m6881" or > -m68040 there is no ICE! > Sorry, I forgot to add "-funswitch-loops" option, so again: The problem is not with "-funswitch-loops" optimization. I get no ICE with these options (-O2 -fipa-cp-clone -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning -funswitch-loops): OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O2 -fipa-cp-clone -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning -funswitch-loops I get ICE with -O3: OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -Wundef -O3 Also, ICE happens ONLY with -m68060 flag! When I use "-m68020 -m6881" or -m68040 there is no ICE! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug c/41095] New: 4x bigger object when compiled with -O3 option
Hi,
When I compile "libavcodec/dsputil.c" file from FFmpeg package with these
options (-O2 -fipa-cp-clone -finline-functions -fgcse-after-reload
-ftree-vectorize -fpredictive-commoning -funswitch-loops):
OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement
-Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common
-fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls
-Wcast-qual -Wwrite-strings -Wundef -O2 -fipa-cp-clone -finline-functions
-fgcse-after-reload -ftree-vectorize -fpredictive-commoning -funswitch-loops
I get "dsputil.o" with size of 306kb.
When I compile "dsputil.c" with -O3 option:
OPTFLAGS= -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement
-Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common
-fomit-frame-pointer -Wall -Wno-switch -Wpointer-arith -Wredundant-decls
-Wcast-qual -Wwrite-strings -Wundef -O3
I get "dsputil.o" with size of 1,18mb.
--
Summary: 4x bigger object when compiled with -O3 option
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ami_stuff at o2 dot pl
GCC host triplet: i686-cygwin
GCC target triplet: m68k-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug c/41095] 4x bigger object when compiled with -O3 option
--- Comment #1 from ami_stuff at o2 dot pl 2009-08-17 20:00 --- Created an attachment (id=18386) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18386&action=view) preprocessed file -O2 -f... -O2 -fipa-cp-clone -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning -funswitch-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug c/41095] 4x bigger object when compiled with -O3 option
--- Comment #2 from ami_stuff at o2 dot pl 2009-08-17 20:02 --- Created an attachment (id=18387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18387&action=view) asm output -O2 -f... -O2 -fipa-cp-clone -finline-functions -fgcse-after-reload -ftree-vectorize -fpredictive-commoning -funswitch-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug c/41095] 4x bigger object when compiled with -O3 option
--- Comment #3 from ami_stuff at o2 dot pl 2009-08-17 20:04 --- Created an attachment (id=18388) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18388&action=view) preprocessed file -O3 -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug c/41095] 4x bigger object when compiled with -O3 option
--- Comment #4 from ami_stuff at o2 dot pl 2009-08-17 20:05 --- Created an attachment (id=18389) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18389&action=view) asm output -O3 -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #9 from ami_stuff at o2 dot pl 2009-08-17 20:11 --- Created an attachment (id=18390) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18390&action=view) preprocessed file -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #10 from ami_stuff at o2 dot pl 2009-08-17 20:11 --- Created an attachment (id=18391) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18391&action=view) asm output -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #11 from ami_stuff at o2 dot pl 2009-08-19 00:28 ---
It ICEs also...
with -m68020 -m68881 -Os options:
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.1.exe -V 4.4.1 -DHAVE_AV_CONFIG_H -I.
-I"/bin/ffmpeg8" -mnobitfield -m68020 -m68881 -std=c99
-Wdeclaration-after-stat
ement -Wdisabled-optimization -fno-math-errno -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE
=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common
-fomit-frame-poin
ter -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual
-Wwrite-stri
ngs -Wundef -Os -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 647 2733 2734 49 libavcodec/mpegvideo.c:1488 (set (reg/v/f:SI 7 d7
[orig:2
93 ptr_y ] [293])
(plus:SI (mem/f:SI (reg:SI 8 a0) [7 S4 A16])
(reg:SI 7 d7 [637]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
with -m68040 -Os options:
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.1.exe -V 4.4.1 -DHAVE_AV_CONFIG_H -I.
-I"/bin/ffmpeg8" -mnobitfield -m68040 -std=c99 -Wdeclaration-after-statement
-W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer
-Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings
-Wun
def -Os -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 647 2733 2734 49 libavcodec/mpegvideo.c:1488 (set (reg/v/f:SI 7 d7
[orig:2
93 ptr_y ] [293])
(plus:SI (mem/f:SI (reg:SI 8 a0) [7 S4 A16])
(reg:SI 7 d7 [637]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
with -m68060 -Os options:
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.1.exe -V 4.4.1 -DHAVE_AV_CONFIG_H -I.
-I"/bin/ffmpeg8" -mnobitfield -m68060 -std=c99 -Wdeclaration-after-statement
-W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common -fomit-frame-pointer
-Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings
-Wun
def -Os -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment differ in
sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 637 2688 2689 49 libavcodec/mpegvideo.c:1488 (set (reg/v/f:SI 7 d7
[orig:2
89 ptr_y ] [289])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug c/40977] Problem with code like this: res = ((uint64_t)resh << 32) | resl;
--- Comment #1 from ami_stuff at o2 dot pl 2009-08-22 00:43 --- Here is asm output from GCC 4.2.5 (-m68060 -fomit-frame-pointer -O3): #NO_APP .text .even .globl _MUL64 _MUL64: movm.l #0x3e00,-(sp) move.l 24(sp),a1 move.l 28(sp),a0 #APP | Inlined umul_ppmm move.l a1,d0 move.l a0,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,d5 #NO_APP tst.l a1 jblt L8 L2: tst.l a0 jbge L4 sub.l a1,d5 jbra L4 L8: sub.l a0,d5 jbra L2 L4: move.l d5,d0 clr.l d1 or.l d6,d1 movm.l (sp)+,#0x7c rts GCC 4.3.2 asm output looks worse: #NO_APP .text .even .globl _MUL64 _MUL64: movem.l #15872,-(sp) move.l 24(sp),d5 move.l 28(sp),a1 #APP ;# 45 "test2.c" 1 | Inlined umul_ppmm move.l d5,d0 move.l a1,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,a0 #NO_APP tst.l d5 jlt L6 tst.l a1 jlt L7 L3: move.l a0,d1 clr.l d2 or.l d6,d2 move.l d1,d0 move.l d2,d1 movem.l (sp)+,#124 rts L7: sub.l d5,a0 move.l a0,d1 clr.l d2 or.l d6,d2 move.l d1,d0 move.l d2,d1 movem.l (sp)+,#124 rts L6: sub.l a1,a0 tst.l a1 jge L3 jra L7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
[Bug c/41095] 4x bigger object when compiled with -O3 option
--- Comment #5 from ami_stuff at o2 dot pl 2009-08-26 20:25 --- -m68060 -O3 ...: GCC 4.1.2 - 385KB GCC 4.2.5 - 386KB GCC 4.3.2 - 777KB GCC 4.4.1 - 1,18MB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug c/40977] Problem with code like this: res = ((uint64_t)resh << 32) | resl;
--- Comment #2 from ami_stuff at o2 dot pl 2009-08-30 16:57 --- With -m68060 -O1 -fomit-frame-pointer: GCC 4.1.2/GCC 4.2.5: #NO_APP .text .even .globl _MUL64 _MUL64: movm.l #0x3e00,-(sp) move.l 28(sp),a1 move.l 24(sp),a0 #APP | Inlined umul_ppmm move.l a0,d0 move.l a1,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,d5 #NO_APP tst.l a0 jbge L2 sub.l a1,d5 L2: tst.l a1 jbge L4 sub.l a0,d5 L4: move.l d5,d0 clr.l d1 or.l d6,d1 movm.l (sp)+,#0x7c rts GCC 4.3.2: #NO_APP .text .even .globl _MUL64 _MUL64: movem.l #16128,-(sp) move.l 32(sp),d5 move.l 28(sp),a0 #APP ;# 45 "test5.c" 1 | Inlined umul_ppmm move.l a0,d0 move.l d5,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d7 add.l d1,d0 move.l d0,a1 #NO_APP tst.l a0 jge L2 sub.l d5,a1 L2: tst.l d5 jge L3 sub.l a0,a1 L3: move.l a1,d1 clr.l d2 or.l d7,d2 move.l d1,d0 move.l d2,d1 movem.l (sp)+,#252 rts GCC 4.4.2: #NO_APP .text .even .globl _MUL64 _MUL64: movem.l #16128,-(sp) move.l 32(sp),a0 move.l 28(sp),a1 #APP ;# 45 "test5.c" 1 | Inlined umul_ppmm move.l a1,d0 move.l a0,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,d5 #NO_APP tst.l a1 jge L2 sub.l a0,d5 L2: tst.l a0 jge L3 sub.l a1,d5 L3: move.l d5,d0 clr.l d1 move.l d0,d2 move.l d1,d3 or.l d6,d3 move.l d2,d6 move.l d3,d7 move.l d2,d0 move.l d7,d1 movem.l (sp)+,#252 rts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
[Bug c/41204] New: GCC 4.4.[0/1/2] generates worse code compared to GCC 4.3.2
Hi,
When I compile this C code:
#include
inline int mid_pred(int a, int b, int c)
{
int t= (a-b)&((a-b)>>31);
a-=t;
b+=t;
b-= (b-c)&((b-c)>>31);
b+= (a-b)&((a-b)>>31);
return b;
}
I get this asm output from GCC 4.3.2 (-m68060 -fomit-frame-pointer -O[2/3]):
#NO_APP
.text
.even
.globl _mid_pred
_mid_pred:
movem.l #14336,-(sp)
move.l 16(sp),d2
move.l 20(sp),d1
move.l d2,d0
sub.l d1,d0
move.l d0,d4
add.l d4,d4
subx.l d4,d4
and.l d0,d4
add.l d4,d1
move.l d1,d3
sub.l 24(sp),d3
move.l d3,d0
add.l d0,d0
subx.l d0,d0
and.l d3,d0
sub.l d0,d1
sub.l d4,d2
sub.l d1,d2
move.l d2,d0
add.l d0,d0
subx.l d0,d0
and.l d2,d0
add.l d1,d0
movem.l (sp)+,#28
rts
When I use GCC 4.4.[0/1/2] with -O2/-O3 option I get worse asm output (2
additional move.ls):
#NO_APP
.text
.even
.globl _mid_pred
_mid_pred:
movem.l #14336,-(sp)
move.l 16(sp),d1
move.l 20(sp),d0
move.l d1,d3
sub.l d0,d3
move.l d3,d2
add.l d2,d2
subx.l d2,d2
and.l d3,d2
add.l d2,d0
move.l d0,d4
sub.l 24(sp),d4
move.l d4,d3
add.l d3,d3
subx.l d3,d3
and.l d4,d3
sub.l d3,d0
move.l d0,d3
sub.l d2,d1
sub.l d0,d1
move.l d1,d2
add.l d2,d2
subx.l d2,d2
and.l d1,d2
move.l d2,d0
add.l d3,d0
movem.l (sp)+,#28
rts
The problematic optimization is -fregmove (-m68060 -fomit-frame-pointer -O[2/3]
-fno-regmove):
#NO_APP
.text
.even
.globl _mid_pred
_mid_pred:
movem.l #14336,-(sp)
move.l 16(sp),d0
move.l 20(sp),d1
move.l d0,d2
sub.l d1,d2
move.l d2,d3
add.l d3,d3
subx.l d3,d3
and.l d3,d2
add.l d2,d1
move.l d1,d3
sub.l 24(sp),d3
move.l d3,d4
add.l d4,d4
subx.l d4,d4
and.l d4,d3
sub.l d3,d1
sub.l d2,d0
sub.l d1,d0
move.l d0,d2
add.l d2,d2
subx.l d2,d2
and.l d2,d0
add.l d1,d0
movem.l (sp)+,#28
rts
--
Summary: GCC 4.4.[0/1/2] generates worse code compared to GCC
4.3.2
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ami_stuff at o2 dot pl
GCC host triplet: i686-cygwin
GCC target triplet: m68k-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41204
[Bug target/40977] Problem with code like this: res = ((uint64_t)resh << 32) | resl;
--- Comment #3 from ami_stuff at o2 dot pl 2009-09-02 15:32 --- GCC 4.5.0 (20090827) - additional move.l compared to GCC 4.4.2 (20090825): #NO_APP .text .even .globl _MUL64 _MUL64: movem.l #16128,-(sp) move.l 28(sp),a0 move.l 32(sp),a1 #APP ;# 45 "2.c" 1 | Inlined umul_ppmm move.l a0,d0 move.l a1,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,d5 #NO_APP move.l d5,d2 tst.l a0 jge L2 sub.l a1,d2 L2: tst.l a1 jge L3 sub.l a0,d2 L3: move.l d2,d0 clr.l d1 move.l d0,d2 move.l d1,d3 or.l d6,d3 move.l d2,d6 move.l d3,d7 move.l d2,d0 move.l d7,d1 movem.l (sp)+,#252 rts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
[Bug target/41095] 4x bigger object when compiled with -O3 option
--- Comment #7 from ami_stuff at o2 dot pl 2009-09-02 15:42 --- GCC 4.5.0 (20090827): 888KB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug c/41277] New: [4.5 regression] libx264 don't want to compile
Hi, I can't compile libx264 with GCC 4.5.0 (20090827), but I can without problems with GCC 4.4.2 (20090825). I include preprocessed problematic file from GCC 4.4.2 and GCC 4.5.0 - "encoder/analyse.c" Regards -- Summary: [4.5 regression] libx264 don't want to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ami_stuff at o2 dot pl GCC host triplet: i686-cygwin GCC target triplet: m68k-amigaos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41277
[Bug c/41277] [4.5 regression] libx264 don't want to compile
--- Comment #1 from ami_stuff at o2 dot pl 2009-09-05 14:03 --- Created an attachment (id=18508) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18508&action=view) preprocessed file from GCC 4.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41277
[Bug c/41277] [4.5 regression] libx264 don't want to compile
--- Comment #2 from ami_stuff at o2 dot pl 2009-09-05 14:03 --- Created an attachment (id=18509) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18509&action=view) preprecessed file from GCC 4.5.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41277
[Bug c/41277] [4.5 regression] libx264 don't want to compile
--- Comment #3 from ami_stuff at o2 dot pl 2009-09-05 14:07 --- $ make_68k_v45 /usr/local/amiga/bin/m68k-amigaos-gcc-4.5.0.exe -V 4.5.0 --save-temp -O2 -finlin e-functions -ffast-math -Wall -I. -DHAVE_MALLOC_H -DWORDS_BIGENDIAN -s -fomit-f rame-pointer -m68060 -c -o encoder/analyse.o encoder/analyse.c In file included from ./common/common.h:683:0, from encoder/analyse.c:31: ./common/macroblock.h: In function 'x264_mb_transform_8x8_allowed': ./common/macroblock.h:465:5: warning: dereferencing type-punned pointer will bre ak strict-aliasing rules In file included from encoder/rdo.c:59:0, from encoder/analyse.c:37: encoder/cabac.c: In function 'x264_cabac_mb8x8_mvd': encoder/cabac.c:462:13: warning: format '%s' expects type 'char *', but argument 5 has type 'int' encoder/analyse.c: In function 'x264_mb_analyse_inter_p16x16': encoder/analyse.c:1205:13: warning: format '%s' expects type 'char *', but argum ent 5 has type 'int' encoder/analyse.c:1217:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1221:5: warning: format '%s' expects type 'char *', but argume nt 5 has type 'int' encoder/analyse.c:1227:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1227:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1230:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p8x8_mixed_ref': encoder/analyse.c:1290:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1295:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p8x8': encoder/analyse.c:1326:5: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1344:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1346:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p16x8': encoder/analyse.c:1393:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1407:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p8x16': encoder/analyse.c:1442:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1456:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p4x4': encoder/analyse.c:1525:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p8x4': encoder/analyse.c:1565:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_p4x8': encoder/analyse.c:1602:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_analyse_inter_b16x16': encoder/analyse.c:1677:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1704:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_cache_mv_p8x8': encoder/analyse.c:1743:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1746:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1747:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1750:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1751:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1754:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1755:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1756:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1757:13: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_cache_mv_b8x8': encoder/analyse.c:1807:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c:1807:9: warning: dereferencing type-punned pointer will break strict-aliasing rules encoder/analyse.c: In function 'x264_mb_cache_mv_b16x8': enco
[Bug c/41277] [4.5 regression] ICE with libx264
-- ami_stuff at o2 dot pl changed: What|Removed |Added Severity|critical|major Summary|[4.5 regression] libx264|[4.5 regression] ICE with |don't want to compile |libx264 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41277
[Bug c/41277] [4.5 regression] libx264 don't want to compile + ICE
-- ami_stuff at o2 dot pl changed: What|Removed |Added Severity|major |critical Summary|[4.5 regression] ICE with |[4.5 regression] libx264 |libx264 |don't want to compile + ICE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41277
[Bug c++/41290] New: [4.5 regression] C++ - libdirac don't want to compile
18 size unit size align 8 context arg-type >> result ignored QI file /usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../ m68k-amigaos/include/c++/4.5.0/bits/basic_ios.h line 443 col 7 size unit size align 8 context > full-name "char_type std::basic_ios<_CharT, _Traits>::widen(char) const [wit h _CharT = char, _Traits = std::char_traits, char_type = char]" pending-inline-info 0x7f1eade8 template-info 0x7fbb9580 saved-insns 0x7f1dce98 chain > make[1]: *** [libdirac_common_la-common.lo] Error 1 -- Summary: [4.5 regression] C++ - libdirac don't want to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ami_stuff at o2 dot pl GCC host triplet: i686-cygwin GCC target triplet: m68k-amigaos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug c++/41290] [4.5 regression] C++ - libdirac don't want to compile
--- Comment #1 from ami_stuff at o2 dot pl 2009-09-07 04:01 --- Created an attachment (id=18523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18523&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1
--- Comment #15 from ami_stuff at o2 dot pl 2009-09-07 19:22 --- GCC 4.4.2 - GCC 4.4.2 (20090825). GCC 4.5.0 - GCC 4.5.0 (20090827). Here are the results: cputime minigzip_340_O1 testa.tif - 33.917 cputime minigzip_340_O2 testa.tif - 30.868 cputime minigzip_340_O3 testa.tif - 31.304 cputime minigzip_442_O1 testa.tif - 39.261 cputime minigzip_442_O2 testa.tif - 37.704 cputime minigzip_442_O3 testa.tif - 41.666 cputime minigzip_450_O1 testa.tif - 41.128 cputime minigzip_450_O2 testa.tif - 37.587 cputime minigzip_450_O3 testa.tif - 37.663 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/41311] New: [4.5 regression] FFmpeg crashes when converting mpg to avi
7;av_log' makes in teger from pointer without a cast ./libavutil/log.h:104:6: note: expected 'int' but argument is of type 'const cha r *' libavcodec/ratecontrol.c:874:9: warning: too many arguments for format libavcodec/ratecontrol.c:936:5: warning: passing argument 2 of 'av_log' makes in teger from pointer without a cast ./libavutil/log.h:104:6: note: expected 'int' but argument is of type 'const cha r *' libavcodec/ratecontrol.c:936:5: warning: too many arguments for format -- Summary: [4.5 regression] FFmpeg crashes when converting mpg to avi Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ami_stuff at o2 dot pl GCC host triplet: i686-cygwin GCC target triplet: m68k-amigaos http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #1 from ami_stuff at o2 dot pl 2009-09-08 18:06 --- Created an attachment (id=18543) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18543&action=view) preprocessed file GCC 4.4.2 -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #2 from ami_stuff at o2 dot pl 2009-09-08 18:07 --- Created an attachment (id=18544) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18544&action=view) asm output GCC 4.4.2 -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #3 from ami_stuff at o2 dot pl 2009-09-08 18:08 --- Created an attachment (id=18545) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18545&action=view) preprocessed file GCC 4.5.0 -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #4 from ami_stuff at o2 dot pl 2009-09-08 18:09 --- Created an attachment (id=18546) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18546&action=view) asm output GCC 4.5.0 -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #5 from ami_stuff at o2 dot pl 2009-09-08 18:10 --- Created an attachment (id=18547) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18547&action=view) preprocessed file GCC 4.5.0 -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #6 from ami_stuff at o2 dot pl 2009-09-08 18:11 --- Created an attachment (id=18548) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18548&action=view) asm output GCC 4.5.0 -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #8 from ami_stuff at o2 dot pl 2009-09-08 18:36 --- I don't know how to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1
--- Comment #16 from ami_stuff at o2 dot pl 2009-09-10 12:58 --- cputime minigzip_412_O1 testa.tif - 34.336 cputime minigzip_412_O2 testa.tif - 34.499 cputime minigzip_412_O3 testa.tif - 34.257 cputime minigzip_425_O1 testa.tif - 36.474 cputime minigzip_425_O2 testa.tif - 35.650 cputime minigzip_425_O3 testa.tif - 35.912 cputime minigzip_432_O1 testa.tif - 39.166 cputime minigzip_432_O2 testa.tif - 35.005 cputime minigzip_432_O3 testa.tif - 38.114 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c/42522] New: [m68k] Wrong code generated with -O2/-O3
Hi,
This is a code from "libavformat/flvdec.c":
static int flv_probe(AVProbeData *p)
{
const uint8_t *d;
d = p->buf;
if (d[0] == 'F' && d[1] == 'L' && d[2] == 'V' && d[3] < 5 && d[5]==0 &&
AV_RB32(d+5)>8) {
return AVPROBE_SCORE_MAX;
}
return 0;
}
When I compile FFmpeg with -O2/-O3 options, FFmpeg doesn't recognize FLV files
("Unknown format"), but when I use -O1 everything works correctly.
Here is asm output when I compile flvdec.c file with -O2:
_flv_probe:
clr.l d0
rts
.even
and here when I use -O1:
_flv_probe:
move.l 4(sp),a0
move.l 4(a0),a0
cmp.b #70,(a0)
jne L3
cmp.b #76,1(a0)
jne L4
cmp.b #86,2(a0)
jne L5
cmp.b #4,3(a0)
jhi L6
tst.b 5(a0)
jne L7
move.l 5(a0),d0
moveq #8,d1
cmp.l d0,d1
jcs L8
clr.l d0
rts
L3:
clr.l d0
rts
L4:
clr.l d0
rts
L5:
clr.l d0
rts
L6:
clr.l d0
rts
L7:
clr.l d0
rts
L8:
moveq #100,d0
rts
.even
I attache proprocessed files + asm output in the archive.
--
Summary: [m68k] Wrong code generated with -O2/-O3
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ami_stuff at o2 dot pl
GCC host triplet: i686-cygwin
GCC target triplet: m68k-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #1 from ami_stuff at o2 dot pl 2009-12-28 20:17 --- Created an attachment (id=19401) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19401&action=view) preprocessed files + asm output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #3 from ami_stuff at o2 dot pl 2009-12-28 20:38 --- No, asm code looks the same like with -O2 option: _flv_probe: clr.l d0 rts .even Here are GCC's options which I used (should be included in the first post): $ make_68k_v45 /bin/ffmpeg13_play/version.sh "/bin/ffmpeg13_play" version.h /usr/local/amiga/bin/m68k-amigaos-gcc-4.5.0.exe -V 4.5.0 -DHAVE_AV_CONFIG_H -I. -I"/bin/ffmpeg13_play" --save-temps -S -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DHAVE_BIGENDIAN=1 -m68060 -std=c99 -fno-common -fomit-frame-pointer -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-s trings -Wundef -O2 -S -fno-math-errno -MMD -MF libavformat/flvdec.d -MT li bavformat/flvdec.o -c -o libavformat/flvdec.o libavformat/flvdec.c $ m68k-amigaos-gcc -V 4.5.0 -v Using built-in specs. COLLECT_GCC=m68k-amigaos-gcc-4.5.0 COLLECT_LTO_WRAPPER=/usr/local/amiga/libexec/gcc/m68k-amigaos/4.5.0/lto-wrapper. exe Target: m68k-amigaos Configured with: /bernd/gcc4/configure --target=m68k-amigaos --with-cpu=m68040 - -prefix=/usr/local/amiga Thread model: single gcc version 4.5.0 20091224 (experimental) (GCC) -- ami_stuff at o2 dot pl changed: What|Removed |Added Severity|normal |major Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #5 from ami_stuff at o2 dot pl 2009-12-28 23:38 ---
I found which optimization doesn't work correctly on my config:
-O2 ("Unknown format"):
_flv_probe:
clr.l d0
rts
.even
-O2 -fno-cse-follow-jumps (works OK):
_flv_probe:
move.l 4(sp),a0
move.l 4(a0),a0
cmp.b #70,(a0)
jeq L10
L7:
clr.l d0
rts
L10:
cmp.b #76,1(a0)
jne L7
cmp.b #86,2(a0)
jne L7
cmp.b #4,3(a0)
jhi L7
tst.b 5(a0)
jne L7
move.l 5(a0),d0
moveq #8,d1
cmp.l d0,d1
jcc L7
moveq #100,d0
rts
.even
--
ami_stuff at o2 dot pl changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #6 from ami_stuff at o2 dot pl 2009-12-29 01:20 --- > Works for me with 4.5.0 20091228. How's that possible? What about GCC 4.4 branch? I just checked with ATARI GCC 4.4.2 m68k compiler and got the same result: /usr/local/cross-mint/bin/m68k-atari-mint-gcc -c -S flvdec_O2.i -m68060 -O2: _flv_probe: link.w %fp,#0 clr.l %d0 unlk %fp rts .even /usr/local/cross-mint/bin/m68k-atari-mint-gcc -c -S flvdec_O2.i -m68060 -O2 -fno-cse-follow-jumps _flv_probe: link.w %fp,#0 move.l 8(%fp),%a0 move.l 4(%a0),%a0 cmp.b #70,(%a0) jeq .L6 .L2: clr.l %d0 unlk %fp rts .L6: cmp.b #76,1(%a0) jne .L2 cmp.b #86,2(%a0) jne .L2 cmp.b #4,3(%a0) jhi .L2 tst.b 5(%a0) jne .L2 move.l 5(%a0),%d0 moveq #8,%d1 cmp.l %d0,%d1 jcc .L2 moveq #100,%d0 unlk %fp rts .even $ /usr/local/cross-mint/bin/m68k-atari-mint-gcc -v Using built-in specs. Target: m68k-atari-mint Configured with: ../gcc-4.4.2-mint-20091017/configure --target=m68k-atari-mint - -prefix=/usr/local/cross-mint --enable-languages=c,c++ --disable-nls --disable-l ibstdcxx-pch --mandir='/man' --infodir='/info' Thread model: single gcc version 4.4.2 (MiNT 20091017) (GCC) http://vincent.riviere.free.fr/soft/m68k-atari-mint/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #17 from ami_stuff at o2 dot pl 2009-12-29 17:29 --- > m68k-amigaos is not a supported target. LOL! So you prefere to not get any bugreports? I reported a few bugs which were next confirmed on the other hardware and after some time fixed, no matter if I use unsupported m68-amigaos target or not. I think that there is no chance to see any m68k-specific bugs fixed, so I will not waste my time in the future. Please don't forget to close the rest of my bugreports, because I also used m68k-amigaos unsupported target. You may also chage status from FIXED to INVALID if you prefere... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug target/41311] [4.5 regression] m68k - FFmpeg crashes when converting mpg to avi
--- Comment #11 from ami_stuff at o2 dot pl 2010-01-02 00:41 ---
The problematic function is as was said "ff_rate_estimate_qscale".
I found out which optimizations causes the problem:
-m68020 -m68881 -O1 -fno-tree-ccp -fno-tree-dominator-opts (works ok).
-m68020 -m68881 -O1 ("Abort trap")
I attache output files from GCC 4.5 20091224. Maybe someone will try to create
a simpler testcase for thie bug in the future. GCC 4.4 and all older versions
of GCC works correctly, so bug was introduced in the GCC 4.5 branch (only for
-m68020/30 -m68881, -m68040 & -m68060 seems to be OK).
--
ami_stuff at o2 dot pl changed:
What|Removed |Added
Summary|[4.5 regression] FFmpeg |[4.5 regression] m68k -
|crashes when converting mpg |FFmpeg crashes when
|to avi |converting mpg to avi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug target/41311] [4.5 regression] m68k - FFmpeg crashes when converting mpg to avi
--- Comment #12 from ami_stuff at o2 dot pl 2010-01-02 00:47 --- Created an attachment (id=19441) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19441&action=view) files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug target/41095] 4x bigger object when compiled with -O3 option
--- Comment #9 from ami_stuff at o2 dot pl 2010-01-02 15:02 --- GCC 4.5.0 (20091224): 840KB When I use "-O3 -fno-inline-functions -fno-unswitch-loops -fno-predictive-commoning -fno-gcse-after-reload -fno-tree-vectorize", size increases to 944KB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug target/41095] 4x bigger object when compiled with -O3 option
--- Comment #10 from ami_stuff at o2 dot pl 2010-01-23 03:26 --- Looks like -mnobitfield option increases object's size more than 100%. I don't know if so big file size increase is correct. Another problem can be noticed with GCC 4.4.2 which generated 45% bigger object than the rest of the 4.x compilers, so maybe some internal settings should be tweaked for this branch. GCC 3.4.0 -m68060 -O3: 185KB -m68060 -O3 -mnobitfield: 265KB GCC 4.1.2: -m68060 -O3: 386KB -m68060 -O3 -mnobitfield: 783KB GCC 4.2.5: -m68060 -O3: 387KB -m68060 -O3 -mnobitfield: 792KB GCC 4.3.2 -m68060 -O3: 378KB -m68060 -O3 -mnobitfield: 781KB GCC 4.4.2: -m68060 -O3: 554KB -m68060 -O3 -mnobitfield: 1,18MB GCC 4.5.0 -m68060 -O3: 383KB -m68060 -O3 -mnobitfield: 840KB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522 ami_stuff changed: What|Removed |Added Known to fail|| --- Comment #15 from ami_stuff 2011-05-03 12:34:47 UTC --- Almost 1,5 year passed and still no one cares to fix a long-standing, critical bug which generates a broken code for m68k target (ffmpeg, sox, ...).
[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized
--- Comment #14 from ami_stuff at o2 dot pl 2010-05-09 13:54 --- Any chance to see this bug fixed in the near future? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
