This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Unit-at-a-time in real world (Re: Development plan *ducks*)
- From: Jan Hubicka <jh at suse dot cz>
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: Jan Hubicka <jh at suse dot cz>, Zack Weinberg <zack at codesourcery dot com>,Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,David Edelsohn <dje at watson dot ibm dot com>,Diego Novillo <dnovillo at redhat dot com>,gcc mailing list <gcc at gcc dot gnu dot org>,Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>,pop at gauvain dot u-strasbg dot fr, Daniel Berlin <dberlin at dberlin dot org>,aj at suse dot de
- Date: Tue, 29 Jul 2003 19:40:33 +0200
- Subject: Unit-at-a-time in real world (Re: Development plan *ducks*)
- References: <20030728191927.GA26264@atrey.karlin.mff.cuni.cz> <200307281936.PAA30478@makai.watson.ibm.com> <20030728204001.GA31710@atrey.karlin.mff.cuni.cz> <1059429748.3649.77.camel@steven.lr-s.tudelft.nl> <8765lm7178.fsf@egil.codesourcery.com> <1059434004.3647.156.camel@steven.lr-s.tudelft.nl> <20030728233200.GH27638@kam.mff.cuni.cz> <1059472209.3651.64.camel@steven.lr-s.tudelft.nl>
> Op di 29-07-2003, om 01:32 schreef Jan Hubicka:
> > > One option is moving out the most recent new features (intermodule,
> > > C++-unit-at-a-time, other bug-causing/uncovering patches) off the trunk
> >
> > Are there so many PR on unit-at-a-time? I hope I've fixed all of them
> > today, but I found only 5 of them so far in the bugzilla and some of
> > other bugs we noticed while building the packages on hammer branch where
> > I backported it for more testing.
>
> You may not yet have discovered all the bugs/regressions unit-at-a-time
> might have introduced. Just because it works for a lot of code doesn't
> mean it will work for all code, or worse, that it will not break other
> code in ways difficult to detect (look for black swans, not white ones).
> > We are about to build all the SuSE Linux pakcages with unit-a-t-atime so
> > it should get enought testing in a week or so.
>
> Cool, good luck! Will those packages be available for download? ;-p
It is just test right now to check that everything really works fine
as I was affraid of the side effects of unit-at-a-time mode. So far I
did hit few bugs, but these were just easy - either simple thinkos or
latent C++ frontend bugs regarding -fsyntax-only unit-at-a-time is based
on. No design issues or similarly complex problems so far.
There are compatibility issues with non-conforming programs tought so we
are now trying to push fixes into official distributions, so these
problems will get fixed even before 3.4 will come out that will be pain
anyway because of C++ compatibility issues, I would guess.
These falls into three main categories
a) program referencing variables
from asm staements and not using __attribute__ ((used)).
Such problems we hit in glibc, prelink, wine and kernel.
One of anoying side effect is that the proper combination of flags for
such variable is __attribute__ ((used)) to instruct compiler to always
emit the variable *together* with __attribute__ ((unused)) that instruct
compiler to not emit warning. This looks funny, so I would guess that
attribute used sould imply __attribute__ ((unused)) and set TREE_USED
flag too. (do you follow the funny logic in the names)?
Another ugly thing is that 3.2 does not support attribute used on
variables so you need ifdef machinery.
b) using toplevel asm statements to change sections of functions (this
is present in gcc runtime and glibc). The proper fix is to use gcc
section attributes or -fno-unit-at-a-time as work around.
c) programs relying on specific order of global variables in the
memory.. oops...
All these tree issues are non-bugs but we may consider making GCC more
friendly (tweaking attribute used and perhaps making variables to be
always output in the program order but I would preffer to not do that
as this would complicate future cache layout optimizations)
Just to inform about the status.
Honza
>
> Gr.
> Steven
>