This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFA: New option: -fno-toplevel-order


Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes:

> > I tested this patch on i686-pc-linux-gnu without Ada.
> > 1) I bootstrapped/compared the patched compiler.
> > 2) I bootstrapped/compared patched compiler with BOOT_CFLAGS="-g -O2
> >    -fno-toplevel-reorder", which compiles the whole compiler with
> >    -fno-toplevel-reorder.
> > 3) I ran the testsuite the usual way.
> > 4) I ran the testsuite with --target_board=unix/-fno-toplevel-reorder,
> >    which runs all the tests with -fno-toplevel-reorder.
> 
> I'd suggest to test a combined tree.  The tree that I use for my work
> at USI has Daniel's patch and I had to modify both crtstuff.c and
> newlib.
> 
> The symptom is that some asm blocks were put *twice* in the output.

My patch does not change the behaviour when using -fno-unit-at-a-time.
And it does not change the behaviour of -funit-at-a-time unless you
specify -fno-toplevel-reorder.  I've already tested crtstuff.c by
changing the explicit -fno-unit-at-a-time to -fno-toplevel-reorder
(that's part of my patch).  I just checked newlib, and it does not
appear to ever use -fno-unit-at-a-time, and it obviously doesn't use
-fno-toplevel-reorder, so I don't see how it could be affected.

Still, I'll give it a try for the mips-elf target, just in case.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]