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]

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


> Jan Hubicka <jh@suse.cz> writes:
> 
> >
> > 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)?
> 
> I think you're right, __attribute__ ((used)) should silence the
> warning.  Send in a patch.
Hmm, OK I see, this is problem of hammer branch only.  mainline gets it
right, so I will fix the branch now.
> 
> >    Another ugly thing is that 3.2 does not support attribute used on
> >    variables so you need ifdef machinery.
> 
> Can the problem be avoided in another way, e.g. by putting the
> variable into the operands list of the asm statement?
Yes, that would work too.
> 
> > 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.
> 
> The C++ front end, down the road, would be happier if -funit-at-a-time
> were the *only* option.  So could you please do what it takes to make
> sure there is another way to handle all such cases?  (Pathological
> examples can be pushed off with 'rewrite in assembly'.)

This is, in general, the case of low level C code.  C++ always did
reordered the functions, so it should not be big deal there.
I am still hoping to push unit-at-a-time into -O2 for 3.4
(depending on results of our build experiment this week) and I would
like to slowly elliminate non-unit-at-a-time paths for 3.5/3.6.
Cgraphunit.c can be easilly extended to deal with incremental compilation too
for c/objc/Java not just unit-at-a-time one avoiding a lot of code
duplication here.

Honza
> 
> zw


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