"Etienne Lorrain" <[EMAIL PROTECTED]> writes:
> > Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> >
> >> Some of those problem may also exist in GCC-4.0 because this
> >> version (and the 4.1 I tested) gives me an increase of 60% of the
> >> code size compared to 3.4.3.
> >
> >
> > This is a serious regression which should be submitted in Bugzilla. Would
> > you please take care of that? It is sufficient to provide a single
> > preprocessed source which shows the code size increase in compilation.
> > GCC4
> > still needs some tuning for -Os.
> >
> > Thanks!
> > --
> > Giovanni Bajo
> >
>
> You probably would not like my target - part of this increase is
> probably due to the fact that some assembler instructions are
> shorter in ia32 protected mode than in ia32 real mode.
>
> I still tryed to extract a simple function and compile it here with
> the options I am using: -fomit-frame-pointer -march=i386 -mrtd
> -fno-builtin -funsigned-char -fverbose-asm -minline-all-stringops
> -mno-align-stringops -Os -ffunction-sections -fstrict-aliasing
> -falign-loops=1 -falign-jumps=1 -falign-functions=2
> -mno-align-double -mpreferred-stack-boundary=2
Interesting set of flags...
> If I compile that with GCC-3.4, I get:
>
> $ size tmp.o
> text data bss dec hex filename
> 243 0 0 243 f3 tmp.o
>
> With GCC-4.0:
>
> $ size tmp.o
> text data bss dec hex filename
> 387 0 0 387 183 tmp.o
>
> Can someone confirm the problem first?
For GCC-4.1
size -f tmp.o
text data bss dec hex filename
322 0 0 322 142 tst.o
Looking at the debugging dump shows that the there's a lot of
variables generate by SRA, indeed after adding
-fno-tree-sra
text data bss dec hex filename
154 0 0 154 9a tst.o
-fno-tree-sra helps this case, but in general SRA is not something you
want to turn off.
