Hi,
> gcc > 4 AOS 68k builds are build from offical gcc sourcetree and there are
> no changes
Yes, I know, but some problems may happens anyway like it happened before
(problems with defines).
I think if there is a problem the best is to compare GCCs from different
sources.
> how much is size
Hi,
> >
> > Here are my results:
> >
> > -m68060 -O3 -fno-unswitch-loops
> >- 12,9kb
> > -m68060 -O3
> >- 12,9kb
> > -m68060 -O2 -finline-functions -fgcse-a
Hi,
> Works fine for me. gcc.dg/tree-ssa/loop-6.c is unswitched with -O3
> but not with -O3 -fno-unswitch-loops.
This one works for me too.
Could you try to compile "deflate.c" from libz?
Here are my results:
-m68060 -O3 -fno-unswitch-loops
Hi,
> Hundreds and hundreds of people read this list, so every low-detail
> "I think there may be a bug" message you send wastes hours of other
> people's time.
Ok, Ok, but if someone will reproduce the same problem on his system I can fill
bugreport,
otherwise I will only waste my time, hours o
Hi,
I found out that when I use "-fno-unswitch-loops" option, it have no effect -
loops are unswitched anyway:
-O3 -fno-unswitch-loops
Because of that to avoid -funswitch-loops optimization I must use something
like this:
-O2 -finline-functions -fpredictive-commoning -fgcse-after-reload
-ftr
Hi,
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 minigzi
Hi,
I found out that GCC 4.4.x build of minigzip from zlib package is a lot slower
compared to GCC 3.4.0 build.
Maybe someone can compile minigzip for his system with GCC 3.4.x and GCC 4.4.x
and compare time of compression
with bigger file? This way we would know if this regression only happens
Hi,
Ok, I didn't use "advenced search". Problem solved.
Regards
Hi,
> You have to be more specific on what you refer to with "search engine
> of bugtracker".
http://gcc.gnu.org/bugzilla/query.cgi
Sorry, these bugs are available for search, but not with "m68k" keyword.
Maybe this can be fixed.
Regards
Hi,
Please someone change the status of these bug reports to be available in the
search engine of bugtracker:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
Thanks
Regards
When I use -O1 with GCC 4.4.0 (-m68060 -fomit-frame-pointer), I get better code.
#include
#include
inline int64_t MUL64(int a, int b)
{
uint32_t resh, resl;
uint32_t au = a;
uint32_t bu = b;
__asm__ ("move.l %0, d5\n\t"
"move.l %1, d4\n\t"
"moveq #16, d3\n\t"
"move.l %0, d2\n\t"
"mulu %1, %0\
Hi,
Here is a C source code which I compiled with GCC 3.4.0 and GCC 4.4.0. GCC
3.4.0 output looks a lot better.
#include
#include
#define umul_ppmm(xh, xl, a, b) \
__asm__ ("| Inlined umul_ppmm\n" \
" move.l %0,%/d5\n" \
" move.l %1,%/d4\n" \
" moveq #16,%/d3\n" \
" move.l %0,%/d2\n" \
" mulu
Hi,
> I assume that you are measuring the speed of the compiled code, not the
> speed of the compiler itself.
Yes.
> Can you open a bug report about this,
> with enough information for other people to reproduce the results (e.g.,
> pointer to source code being compiled and input file(s)).
Done.
Hi,
I notice about 20% speed regression with GCC 4.4.0 PNGCrush build compared to
GCC 3.4.0 build (Amiga 68...@50mhz).
CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s
Here are the results:
GCC 3.4.0:
CPU time used = 267.340 seconds (decoding 16.940,
encoding 247.800, other
14 matches
Mail list logo
