This is the mail archive of the gcc@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]

Unit-at-a-time in real world (Re: Development plan *ducks*)


> 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
> 


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